[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] DM MULTIPATH: Allow dm to send larger request if underlying device set to larger max_sectors value

On Mon, Jul 09 2012 at  9:16am -0400,
Mike Snitzer <snitzer redhat com> wrote:

> 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_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

Very interesting case that we haven't seen raised before.  This will
require block layer changes (DM will then get the change for free).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]