On Tue, Jan 9, 2018 at 12:35 AM, Alex Elder <elder@xxxxxxxx> wrote:
> On 01/08/2018 12:51 PM, Ilya Dryomov wrote:
>> Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped
>> max_segments (unsigned short) to max_hw_sectors (unsigned int).
>> max_hw_sectors is set to the number of 512-byte sectors in an object
>> and overflows unsigned short for 32M (largest possible) objects, making
>> the block layer resort to handing us single segment (i.e. single page
>> or even smaller) bios in that case.
>>
>> Cc: stable@xxxxxxxxxxxxxxx
>> Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments")
>> Signed-off-by: Ilya Dryomov <idryomov@xxxxxxxxx>
>
> Is it OK for max_segments to be bigger than max_hw_sectors?
I think so. max_hw_sectors (or rather max_sectors -- a soft limit
capped by max_hw_sectors hard limit) limits the size of the request.
max_segments limits the number of segments (~ bvecs) and rbd is fine
with any number.
>
> I didn't investigate but the question occurred to me, since you're
> fixing max_segments regardless of segment size, but not doing that
> to the other limits being set.
Yeah, queue_max_segment_size could be UINT_MAX and we could probably
disable SG merging (BLK_MQ_F_SG_MERGE) which we don't benefit from.
This is a small fix intended for stable though.
Thanks for the review!
Ilya
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
