[resend with updated list address and pruning addresses that bounced]
Reviving this discussion, as it still seems useful to incorporate now that BLOCK_STATUS is only recently part of the standard.
On 12/14/2016 11:09 AM, Wouter Verhelst wrote:
One thing I've been thinking about that we might want to add: There may be cases where a server, in performing the required calls to be able to handle a BLOCK_STATUS request, will end up with more information than the client asked; e.g., if the client asked information in the base:allocation context on an extent at offset X of length Y, then the server might conceivably do an lseek(SEEK_DATA) and/or lseek(SEEK_HOLE). The result of that call might be that the file offset will now point to a location Z, where Z > (X+Y). Currently, our spec says "the sum of the *length* fields MUST not be greater than the overall *length* of request". This means that in essense, the server then has to throw away the information it has on the range Z - (X + Y). In case a client was interested in that information, that seems like a waste. I would therefore like to remove that requirement, by rephrasing that "sum of the *length* fields" thing into something along the following lines: In case the server returns N extents, the sum of the *length* fields of the first N-1 extents MUST NOT be greater than the overall *length* of the request. The final extent MAY exceed the length of the request if the server has that information anyway as a side effect of looking up the required information and wishes to share it. This would then result in the fact that the "length" field in the BLOCK_STATUS command would be little more than a hint, since we're saying that a server can return more data than requested (if it's available anyway) and less data than requested (if it would be too resource-intensive to provide all the information). Not sure whether all that makes much sense anymore, but hey. In addition, the combination of a server providing more information than requested with a "REQ_ONE" flag and a length field of zero could be an interesting way to enumerate a whole export, too. Essentially, we could define that as a client saying "I'm interested in what the size of the extent at offset X is, and what its properties are". Thoughts?
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org