On Mon, Jul 09 2012 at 9:16am -0400, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > On Mon, Jul 09 2012 at 9:00am -0400, > Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > On Sun, Jul 08 2012 at 1:59pm -0400, > > Chauhan, Vijay <Vijay.Chauhan@xxxxxxxxxx> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
