From: Mike Snitzer <snitzer@redhat.com>
To: "Chauhan, Vijay" <Vijay.Chauhan@netapp.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
"Moger, Babu" <Babu.Moger@netapp.com>,
"Stankey, Robert" <Robert.Stankey@netapp.com>
Subject: Re: DM MULTIPATH: Allow dm to send larger request if underlying device set to larger max_sectors value
Date: Mon, 9 Jul 2012 09:16:11 -0400 [thread overview]
Message-ID: <20120709131611.GD30048@redhat.com> (raw)
In-Reply-To: <20120709130052.GC30048@redhat.com>
On Mon, Jul 09 2012 at 9:00am -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Sun, Jul 08 2012 at 1:59pm -0400,
> Chauhan, Vijay <Vijay.Chauhan@netapp.com> wrote:
>
> > Even though underlying paths are set with larger value for max_sectors, dm
> > sets 1024(i.e 512KB) for max_sectors as default. max_sectors for dm
> > device can be reset through sysfs but any time map is updated, max_sectors
> > is again set back to default. This patch gets the minimum of max_sectors from
> > physical paths and sets it to dm device.
>
> There shouldn't be any need for additional DM overrides for max_sectors.
>
> DM will stack the limits for all underlying devices each table reload
> (via dm_calculate_queue_limits). And max_sectors is properly stacked in
> the block layer's bdev_stack_limits (called by dm_set_device_limits).
>
> So is something resetting max_sectors with sysfs? multipathd?
BLK_DEF_MAX_SECTORS = 1024
blk_set_stacking_limits: lim->max_sectors = BLK_DEF_MAX_SECTORS
But that just establishes the default, the stacking done by
blk_stack_limits will reduce 'max_sectors' accordingly based on the
underlying paths' max_sectors.
I can clearly see that max_sectors is reduced according to the
underlying device(s):
# multipath -ll
mpathe (36003005700ec1890167a7e5953effb87) dm-5 LSI,RAID 5/6 SAS 6G
size=465G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
`- 0:2:4:0 sde 8:64 active ready running
# cat /sys/block/sde/queue/max_sectors_kb
240
# cat /sys/block/dm-5/queue/max_sectors_kb
240
next prev parent reply other threads:[~2012-07-09 13:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-08 17:59 [PATCH] DM MULTIPATH: Allow dm to send larger request if underlying device set to larger max_sectors value Chauhan, Vijay
2012-07-09 1:01 ` Alasdair G Kergon
2012-07-09 12:34 ` Chauhan, Vijay
2012-07-09 13:00 ` Mike Snitzer
2012-07-09 13:16 ` Mike Snitzer [this message]
2012-07-09 13:40 ` Mike Snitzer
2012-07-09 14:14 ` [PATCH] block: do not artificially constrain max_sectors for stacking drivers Mike Snitzer
2012-07-09 14:57 ` [PATCH v2] " Mike Snitzer
2012-07-09 22:57 ` Mike Snitzer
2012-07-10 19:10 ` Chauhan, Vijay
2012-07-10 19:18 ` Mike Snitzer
2012-08-01 0:39 ` [RESEND PATCH] " Mike Snitzer
2012-08-01 8:45 ` Jens Axboe
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=20120709131611.GD30048@redhat.com \
--to=snitzer@redhat.com \
--cc=Babu.Moger@netapp.com \
--cc=Robert.Stankey@netapp.com \
--cc=Vijay.Chauhan@netapp.com \
--cc=dm-devel@redhat.com \
/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).