Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

On 04/04/2016 03:07 PM, Alex Bligh wrote:
> 
> On 4 Apr 2016, at 21:26, Eric Blake <eblake@redhat.com> wrote:
> 
>> Huh? The current proposal _requires_ these to be separate queries.  You
>> cannot query dirtiness at the same time as allocation, because the value
>> of NBD_CMD_FLAG_DIRTY is distinct between the two queries.
> 
> OK, so you can ask for either (1) or (2), but not both. I see. I misread
> that. I still think Denis's idea of selecting a bitmap to query works better.

I'm still not sure I follow what you are proposing in 'selecting a
bitmap', at least not without also needing to expand the protocol to
allow for a structured command that has more than a fixed-length message
size (currently all commands except NBD_CMD_WRITE) or a self-described
size (NBD_CMD_WRITE).  Would this bitmap id be specified as an integer
(32 bits?) as an arbitrary UTF-8 string? or as something else?  And
since we _already_ documented that querying dirty information requires
out-of-band coordination, why can't the out-of-band communication convey
the bitmap selection, so that the NBD command then just reads the dirty
status of the already-selected bitmap?

It was Paolo's suggestion to document that querying dirty status is only
useful with out-of-band coordination, at which point, why bloat the NBD
protocol with details that are better left to that external
coordination?  Wouter had a valid complaint that v1 was unspecified (it
said that being "dirty" was implementation defined, but gave no other
meaning and a server could use random numbers and still be compliant);
v2 picked up Paolo's wording suggestion against v1 that tries to make it
obvious that being "dirty" is still implementation defined, but that the
definition is whatever it takes for a coordination with out-of-band
information to provide useful results.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]