block: do not artificially constrain max_sectors for stacking drivers
blk_set_stacking_limits() is intended to allow stacking drivers to build
up the limits of the stacked device based on the underlying devices'
limits. But in the case of 'max_sectors' the default of
BLK_DEF_MAX_SECTORS (1024) doesn't allow the stacking driver to inherit
a max_sectors larger than 1024.
It is now clear that this artificial limit is getting in the way so
change blk_set_stacking_limits's max_sectors to UINT_MAX (which allows
stacking drivers like dm-multipath to inherit 'max_sectors' from the
underlying paths).
blk_limits_max_hw_sectors() must allow stacking drivers to not have
max_sectors set to BLK_DEF_MAX_SECTORS as a side-effect. Move that
historic constraint to blk_queue_max_hw_sectors().
Reported-by: Vijay Chauhan <vijay.chauhan@netapp.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
---
block/blk-settings.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
v2: tweak blk_limits_max_hw_sectors and blk_queue_max_hw_sectors
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
07-09-2012, 10:57 PM
Mike Snitzer
block: do not artificially constrain max_sectors for stacking drivers
On Mon, Jul 09 2012 at 10:57am -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> blk_set_stacking_limits() is intended to allow stacking drivers to build
> up the limits of the stacked device based on the underlying devices'
> limits. But in the case of 'max_sectors' the default of
> BLK_DEF_MAX_SECTORS (1024) doesn't allow the stacking driver to inherit
> a max_sectors larger than 1024.
>
> It is now clear that this artificial limit is getting in the way so
> change blk_set_stacking_limits's max_sectors to UINT_MAX (which allows
> stacking drivers like dm-multipath to inherit 'max_sectors' from the
> underlying paths).
>
> blk_limits_max_hw_sectors() must allow stacking drivers to not have
> max_sectors set to BLK_DEF_MAX_SECTORS as a side-effect. Move that
> historic constraint to blk_queue_max_hw_sectors().
>
> Reported-by: Vijay Chauhan <vijay.chauhan@netapp.com>
> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> Cc: Martin K. Petersen <martin.petersen@oracle.com>
> ---
> block/blk-settings.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> v2: tweak blk_limits_max_hw_sectors and blk_queue_max_hw_sectors
As it happens, v2's changes to blk_limits_max_hw_sectors and
blk_queue_max_hw_sectors are not strictly required in order for existing
stacking drivers to have have an unconstrained max_sectors. Dropping
those changes also allows for consistency across both block functions.
So I'd be happy if v1 were to be staged for 3.6. NetApp: it would be
great if you could confirm that v1 does in fact address the max_sectors
issue you reported.
Thanks,
Mike
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
07-10-2012, 07:10 PM
"Chauhan, Vijay"
block: do not artificially constrain max_sectors for stacking drivers
On Tuesday, July 10, 2012 4:27 AM, Mike Wrote:
>As it happens, v2's changes to blk_limits_max_hw_sectors and
>blk_queue_max_hw_sectors are not strictly required in order for existing
>stacking drivers to have have an unconstrained max_sectors. Dropping
>those changes also allows for consistency across both block functions.
>
>So I'd be happy if v1 were to be staged for 3.6. NetApp: it would be
>great if you could confirm that v1 does in fact address the max_sectors
>issue you reported.
>
>Thanks,
>Mike
Mike, Thanks for the quick fix. I verified with Patch v1 and it resolves this issue.
Thanks,
Vijay
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
07-10-2012, 07:18 PM
Mike Snitzer
block: do not artificially constrain max_sectors for stacking drivers
On Tue, Jul 10 2012 at 3:10pm -0400,
Chauhan, Vijay <Vijay.Chauhan@netapp.com> wrote:
> On Tuesday, July 10, 2012 4:27 AM, Mike Wrote:
> >As it happens, v2's changes to blk_limits_max_hw_sectors and
> >blk_queue_max_hw_sectors are not strictly required in order for existing
> >stacking drivers to have have an unconstrained max_sectors. Dropping
> >those changes also allows for consistency across both block functions.
> >
> >So I'd be happy if v1 were to be staged for 3.6. NetApp: it would be
> >great if you could confirm that v1 does in fact address the max_sectors
> >issue you reported.
> >
> >Thanks,
> >Mike
>
> Mike, Thanks for the quick fix. I verified with Patch v1 and it resolves this issue.
Great, thanks for testing. I assume Jens will be OK with staging v1 of
this patch for 3.6 once he gets back from vacation.
Jens please feel free to add the following to v1's patch header:
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
08-01-2012, 08:45 AM
Jens Axboe
block: do not artificially constrain max_sectors for stacking drivers
On 08/01/2012 02:39 AM, Mike Snitzer wrote:
> blk_set_stacking_limits is intended to allow stacking drivers to build
> up the limits of the stacked device based on the underlying devices'
> limits. But defaulting 'max_sectors' to BLK_DEF_MAX_SECTORS (1024)
> doesn't allow the stacking driver to inherit a max_sectors larger than
> 1024 -- due to blk_stack_limits' use of min_not_zero.
>
> It is now clear that this artificial limit is getting in the way so
> change blk_set_stacking_limits's max_sectors to UINT_MAX (which allows
> stacking drivers like dm-multipath to inherit 'max_sectors' from the
> underlying paths).
Thanks Mike (and Vijay), applied for 3.6.
--
Jens Axboe
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel