[Top][All Lists]

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

Re: [Qemu-block] [PATCH v2 05/17] nbd: Advertise realistic limits to blo

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v2 05/17] nbd: Advertise realistic limits to block layer
Date: Wed, 22 Jun 2016 14:58:14 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 06/15/2016 07:38 AM, Paolo Bonzini wrote:
> On 14/06/2016 23:30, Eric Blake wrote:
>> We were basing the advertisement of maximum discard and transfer
>> length off of UINT32_MAX, but since the rest of the block layer
>> has signed int limits on a transaction, nothing could ever reach
>> that maximum, and we risk overflowing an int once things are
>> converted to byte-based rather than sector-based limits.  What's
>> more, we DO have a much smaller limit: both the current kernel
>> and qemu-nbd have a hard limit of 32M on a read or write
>> transaction, and while they may also permit up to a full 32 bits
>> on a discard transaction, the upstream NBD protocol is proposing
>> wording that without any explicit advertisement otherwise,
>> clients should limit ALL requests to the same limits as read and
>> write, even though the other requests do not actually require as
>> many bytes across the wire.  So the better limit to tell the
>> block layer is 32M for both values.

>>  static void nbd_refresh_limits(BlockDriverState *bs, Error **errp)
>>  {
>> -    bs->bl.max_discard = UINT32_MAX >> BDRV_SECTOR_BITS;
>> -    bs->bl.max_transfer_length = UINT32_MAX >> BDRV_SECTOR_BITS;
>> +    bs->bl.max_discard = NBD_MAX_SECTORS;
>> +    bs->bl.max_transfer_length = NBD_MAX_SECTORS;
>>  }
>>  static int nbd_co_discard(BlockDriverState *bs, int64_t sector_num,
> Acked-by: Paolo Bonzini <address@hidden>
> Cc: address@hidden

This one won't apply on stable without the previous one; for that
matter, it is the previous one that actually changes behavior (until
later patches land, the block layer is ignoring what NBD advertises to
the block layer), while this one has no discernible effect except
avoiding latent bugs on future patches.  So in my v3 series, I'm only
putting CC: stable on 4/17, not 5.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]