Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status

[John Snow <jsnow@redhat.com>]

On 12/14/2016 12:09 PM, Wouter Verhelst wrote:
> On Wed, Dec 14, 2016 at 03:08:40PM +0000, Alex Bligh wrote:
>> (NB: I've already applied this and pushed it)
> 
> Thanks.
> 
>> * Change NBD_OPT_LIST_METADATA etc. to explicitly send a list of queries
>>   and add a count of queries so we can extend the command later (rather than
>>   rely on the length of option)
> 
> Sure, that works.
> 
>> * For NBD_OPT_LIST_METADATA make absence of any query (as opposed to zero
>>   length query) list all contexts, as absence of any query is now simple.
>>
>> * Move definition of namespaces in the document to somewhere more appopriate.
>>
>> * Various other minor changes as discussed on the mailing list
> 
> Right. I think we're getting close to a good spec now, for this thing.
> 
> 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?
> 

No complaints here. Even though it becomes a bit of a hint, it still
establishes some limitations. It's good enough, I think.

--js