[RFC PATCH] block: change max_segments default to USHRT_MAX

[RFC PATCH] block: change max_segments default to USHRT_MAX

[Mike Snitzer]

The reported problem was that a DM multipath device's max_segemnts was
constrained to BLK_MAX_SEGMENTS (128) even though the underlying paths'
max_segments were larger.  For example, SCSI establishes a max_segments
of SCSI_MAX_SG_CHAIN_SEGMENTS (2048).

If blk_set_default_limits() sets a block limit's value that is less than
the possible range of values for that limit, stacked devices will never
properly stack the affected limit via blk_stack_limits() if
min_not_zero() is used.

BLK_MAX_SEGMENTS (128) is not the maximum value that may be established
for the max_segments limit.  Setting max_segments to a default of
USHRT_MAX (65535) allows for proper stacking.  Device drivers use
blk_queue_max_segments() to override this default.

Reported-by: Shuichi Ihara <sihara@ddn.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
---
 block/blk-settings.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[NOTE: I avoided changing BLK_MAX_SEGMENTS to 2048 or USHRT_MAX but
that may be the more appropriate fix.  Or splitting BLK_MAX_SEGMENTS
to BLK_DEF_MAX_SEGMENTS=2048 and BLK_SAFE_MAX_SEGMENTS=128.]

diff --git a/block/blk-settings.c b/block/blk-settings.c
index fa1eb04..0ec98e0 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -110,7 +110,7 @@ EXPORT_SYMBOL_GPL(blk_queue_lld_busy);
  */
 void blk_set_default_limits(struct queue_limits *lim)
 {
-	lim->max_segments = BLK_MAX_SEGMENTS;
+	lim->max_segments = USHRT_MAX;
 	lim->max_integrity_segments = 0;
 	lim->seg_boundary_mask = BLK_SEG_BOUNDARY_MASK;
 	lim->max_segment_size = BLK_MAX_SEGMENT_SIZE;
-- 
1.7.4.4

Re: [RFC PATCH] block: change max_segments default to USHRT_MAX

[Martin K. Petersen]

>>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:

Mike> The reported problem was that a DM multipath device's max_segemnts
Mike> was constrained to BLK_MAX_SEGMENTS (128) even though the
Mike> underlying paths' max_segments were larger.  For example, SCSI
Mike> establishes a max_segments of SCSI_MAX_SG_CHAIN_SEGMENTS (2048).

I'd rather that we revisited the patches I posted a while back where we
have different defaults for LLDs and stacking drivers.

I'll freshen those up and post them later today. I have a few concalls
to clear first...

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [RFC PATCH] block: change max_segments default to USHRT_MAX

[Mike Snitzer]

On Tue, Nov 29 2011 at 12:59pm -0500,
Martin K. Petersen <martin.petersen@oracle.com> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
> 
> Mike> The reported problem was that a DM multipath device's max_segemnts
> Mike> was constrained to BLK_MAX_SEGMENTS (128) even though the
> Mike> underlying paths' max_segments were larger.  For example, SCSI
> Mike> establishes a max_segments of SCSI_MAX_SG_CHAIN_SEGMENTS (2048).
> 
> I'd rather that we revisited the patches I posted a while back where we
> have different defaults for LLDs and stacking drivers.

Don't think I ever saw those patches.  But it isn't immediately clear to
me why we'd want to have to continue to think in different terms
depending on whether we're LLD or stacked (especially for max_segments).

Though I do understand why we need it in some cases, e.g.: the existing
conflicting default for discard_zeroes_data (block vs DM).  It is
unfortunate yet necessary given the current limits stacking.

(We _could_ make dzd=0 the uniform default if DM were made to look at
all devices in a table and decide whether dzd should be enabled,
something like we do for discards with dm_table_supports_discards())

Thing is we have the block layer doing the stacking of limits.. so
ideally the stacking drivers wouldn't need to work so hard to keep the
block layer non-committal on differentiating between LLD vs stacked.

I'd imagine your patches will formalize an interface that gets us away
from what may seem, to the uninitiated, like adhoc twiddling of certain
limits.

> I'll freshen those up and post them later today.

Great (please cc dm-devel when you post them).

Long story short, I look forward to seeing your patches ;)

Thanks!