<div dir="ltr">Hannes,<div><br></div><div>While you are working on the feature code, is there a sequence of system commands I can use ?</div><div><br></div><div>thanks,</div><div><br></div><div>Pankaj</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 14, 2018 at 1:53 PM, Mike Snitzer <span dir="ltr"><<a href="mailto:snitzer@redhat.com" target="_blank">snitzer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 14 2018 at 12:13pm -0400,<br>
Mike Snitzer <<a href="mailto:snitzer@redhat.com">snitzer@redhat.com</a>> wrote:<br>
<br>
> On Sun, May 13 2018 at  8:47pm -0400,<br>
> Pankaj Agarwal <<a href="mailto:pankaj@releasemanager.in">pankaj@releasemanager.in</a>> wrote:<br>
> <br>
> >    Hi,<br>
> >    How do i set the nr_request value for LV's as it's not writable like other<br>
> >    drives on a linux system.<br>
> >    LV's are set as dm-0 and dm-1 on my system.<br>
> >     #cat /sys/block/dm-0/queue/nr_<wbr>requests<br>
> >    128<br>
> >    # echo 256 > /sys/block/dm-0/queue/nr_<wbr>requests<br>
> >    -bash: echo: write error: Invalid argument<br>
> <br>
> In the block layer, bio-based devices cannot have their nr_requests<br>
> changed, see: block/blk-sysfs.c:queue_<wbr>requests_store()<br>
> <br>
> So any bio-based DM device (e.g. linear target) won't be allowed to<br>
> change nr_requests.<br>
> <br>
> The only way to change this would be from the bottom up:<br>
> 1) change the underlying request-based device(s) (e.g. /dev/sda)<br>
> 2) dmsetup suspend + dmsetup resume any bio-based DM device(s) that are<br>
>    stacked ontop of the request-based device(s) you changed in 1)<br>
>    -- this will restack the queue_limits from the bottom up; so the DM<br>
>    device will then reflect the underlying devices' limits.<br>
<br>
</span>I was mistaken.  DM core (in the kernel) will only restack the<br>
queue_limits (nr_requests included) if a new DM table is loaded.<br>
<br>
So a simple suspend+resume will _not_ change the bio-based DM device's<br>
queue_limits:<br>
<br>
[root@thegoat ~]# lsblk /dev/nullb0<br>
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT<br>
nullb0 253:0    0  250G  0 disk<br>
└─foo  252:0    0  250G  0 dm<br>
[root@thegoat ~]# cat /sys/block/nullb0/queue/nr_<wbr>requests<br>
128<br>
[root@thegoat ~]# cat /sys/block/dm-0/queue/nr_<wbr>requests<br>
128<br>
[root@thegoat ~]# echo 64 > /sys/block/nullb0/queue/nr_<wbr>requests<br>
[root@thegoat ~]# cat /sys/block/nullb0/queue/nr_<wbr>requests<br>
64<br>
[root@thegoat ~]# cat /sys/block/dm-0/queue/nr_<wbr>requests<br>
128<br>
[root@thegoat ~]# dmsetup suspend foo<br>
[root@thegoat ~]# dmsetup resume foo<br>
[root@thegoat ~]# cat /sys/block/dm-0/queue/nr_<wbr>requests<br>
128<br>
<br>
There was some related work started in this area by Hannes (now cc'd)<br>
during LSF last month.  He added a chain-notifier to DM devices so that<br>
if any underlying devices (devices referenced in a DM device's table)<br>
were changed then the enture device stack would have its limits<br>
reloaded.<br>
<br>
Not sure where Hannes ended up with that.  Would love to get it polished<br>
now and staged for 4.18 inclusion.<br>
<br>
Hannes?<br>
</blockquote></div><br></div>