qemu-devel
[Top][All Lists]
Advanced

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

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


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status
Date: Wed, 14 Dec 2016 20:33:48 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

14.12.2016 20:09, 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?


Good, I'm for it. May be, in such wording there are too much information about implementation (again, server can do it if it _wants_, is it a side effect or not is implementation defined). In other words, "if the server..." is better read as an example, not requirement. But it's not important.

--
Best regards,
Vladimir




reply via email to

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