qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on se


From: Paolo Bonzini
Subject: Re: [Qemu-block] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on server
Date: Thu, 23 Feb 2017 14:13:32 +0100
User-agent: 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 =
cluster size).

>>    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.

Paolo

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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