[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on se
Re: [Qemu-devel] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on server
Thu, 23 Feb 2017 14:13:32 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
On 22/02/2017 21:34, Eric Blake wrote:
>> Oh, so it's the smallest "good" transfer size, or the preferred
>> alignment. That's not the same as the SCSI definition, which is:
>> If a device server receives one of these commands with a transfer
>> size greater than this value, then the device server may incur
>> delays in processing the command. An OPTIMAL TRANSFER LENGTH field
>> set to 0000_0000h indicates that the device server does not report
>> an optimal transfer size.
> Hmm - that's yet another limit. I don't know if our block layer exposes
> it, or if it should expose it.
It exposes it in opt_transfer. :) The only driver that sets
opt_transfer is the iSCSI driver and uses the SCSI meaning.
>> It's more similar to the physical block size:
> Indeed; at least that was my intent (picking a size that will avoid
> read-modify-write pessimations, as well as reflecting granularity of
> trim/zero operations).
The two are not necessarily related. Granularity of trim/zero is
usually a multiple of the sector size (for example qcow2 will have
physical block size = host physical block size, and unmap granularity =
>> When using logical block access commands (see 4.2.2), application
>> clients should:
>> a) specify an LBA that is aligned to a physical block boundary; and
>> b) access an integral number of physical blocks, provided that the
>> access does not go beyond the last LBA on the medium.
>> So I'd rather ignore it in the client, and send 4096 in the server.
> Does that mean our BlockLimits structure documentation needs a tweak,
> too? It currently reads:
> /* Optimal transfer length in bytes. A power of 2 is best but not
> * mandatory. Must be a multiple of bl.request_alignment, or 0 if
> * no preferred size */
> uint32_t opt_transfer;
> Are we trying to track both optimum size in the SCSI sense _and_ block
> size in the O_DIRECT sense?
As of now, just in the SCSI sense.
Description: OpenPGP digital signature
[Qemu-devel] [PATCH v4 5/8] nbd: Implement NBD_OPT_GO on server, Eric Blake, 2017/02/20
[Qemu-devel] [PATCH v4 8/8] nbd: Implement NBD_INFO_BLOCK_SIZE on client, Eric Blake, 2017/02/20
- [Qemu-devel] [PATCH v4 4/8] nbd: Expose and debug more NBD constants, (continued)