From: Mike Snitzer <snitzer@redhat.com>
To: Pankaj Agarwal <pankaj@releasemanager.in>
Cc: Hannes Reinecke <hare@suse.com>,
dm-devel@redhat.com, linux-lvm@redhat.com
Subject: Re: [linux-lvm] how to set higher then 128 nr_requests on LV's
Date: Mon, 14 May 2018 13:53:54 -0400 [thread overview]
Message-ID: <20180514175354.GA15053@redhat.com> (raw)
In-Reply-To: <20180514161312.GA14685@redhat.com>
On Mon, May 14 2018 at 12:13pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Sun, May 13 2018 at 8:47pm -0400,
> Pankaj Agarwal <pankaj@releasemanager.in> wrote:
>
> > Hi,
> > How do i set the nr_request value for LV's as it's not writable like other
> > drives on a linux system.
> > LV's are set as dm-0 and dm-1 on my system.
> > #cat /sys/block/dm-0/queue/nr_requests
> > 128
> > # echo 256 > /sys/block/dm-0/queue/nr_requests
> > -bash: echo: write error: Invalid argument
>
> In the block layer, bio-based devices cannot have their nr_requests
> changed, see: block/blk-sysfs.c:queue_requests_store()
>
> So any bio-based DM device (e.g. linear target) won't be allowed to
> change nr_requests.
>
> The only way to change this would be from the bottom up:
> 1) change the underlying request-based device(s) (e.g. /dev/sda)
> 2) dmsetup suspend + dmsetup resume any bio-based DM device(s) that are
> stacked ontop of the request-based device(s) you changed in 1)
> -- this will restack the queue_limits from the bottom up; so the DM
> device will then reflect the underlying devices' limits.
I was mistaken. DM core (in the kernel) will only restack the
queue_limits (nr_requests included) if a new DM table is loaded.
So a simple suspend+resume will _not_ change the bio-based DM device's
queue_limits:
[root@thegoat ~]# lsblk /dev/nullb0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nullb0 253:0 0 250G 0 disk
└─foo 252:0 0 250G 0 dm
[root@thegoat ~]# cat /sys/block/nullb0/queue/nr_requests
128
[root@thegoat ~]# cat /sys/block/dm-0/queue/nr_requests
128
[root@thegoat ~]# echo 64 > /sys/block/nullb0/queue/nr_requests
[root@thegoat ~]# cat /sys/block/nullb0/queue/nr_requests
64
[root@thegoat ~]# cat /sys/block/dm-0/queue/nr_requests
128
[root@thegoat ~]# dmsetup suspend foo
[root@thegoat ~]# dmsetup resume foo
[root@thegoat ~]# cat /sys/block/dm-0/queue/nr_requests
128
There was some related work started in this area by Hannes (now cc'd)
during LSF last month. He added a chain-notifier to DM devices so that
if any underlying devices (devices referenced in a DM device's table)
were changed then the enture device stack would have its limits
reloaded.
Not sure where Hannes ended up with that. Would love to get it polished
now and staged for 4.18 inclusion.
Hannes?
next prev parent reply other threads:[~2018-05-14 17:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 0:47 [linux-lvm] how to set higher then 128 nr_requests on LV's Pankaj Agarwal
2018-05-14 14:21 ` Zdenek Kabelac
2018-05-14 16:13 ` Mike Snitzer
2018-05-14 17:53 ` Mike Snitzer [this message]
2018-05-14 23:57 ` Pankaj Agarwal
2018-05-15 0:22 Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180514175354.GA15053@redhat.com \
--to=snitzer@redhat.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.com \
--cc=linux-lvm@redhat.com \
--cc=pankaj@releasemanager.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).