On 04/04/2016 03:07 PM, Alex Bligh wrote: > > On 4 Apr 2016, at 21:26, Eric Blake <ebl...@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
signature.asc
Description: OpenPGP digital signature