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
signature.asc
Description: OpenPGP digital signature
