[dm-devel] DM MULTIPATH: Allow dm to send larger request if underlying device set to larger max_sectors value
Mike Snitzer
snitzer at redhat.com
Mon Jul 9 13:40:41 UTC 2012
On Mon, Jul 09 2012 at 9:16am -0400,
Mike Snitzer <snitzer at redhat.com> wrote:
> On Mon, Jul 09 2012 at 9:00am -0400,
> Mike Snitzer <snitzer at redhat.com> wrote:
>
> > On Sun, Jul 08 2012 at 1:59pm -0400,
> > Chauhan, Vijay <Vijay.Chauhan at 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):
Ah, but you were saying max_hw_sectors and max_sectors may be larger
than 1024 and that you'd like to have the multipth device's max-sectors
reflect the larger values (not be capped by the block layer's
BLK_DEF_MAX_SECTORS).
Very interesting case that we haven't seen raised before. This will
require block layer changes (DM will then get the change for free).
Mike
More information about the dm-devel
mailing list