Re: [Qemu-devel] [PATCH 6/9] nbd: BLOCK_STATUS for standard get_block_status function: client part

[Vladimir Sementsov-Ogievskiy]

16.02.2018 23:40, Eric Blake wrote:
> On 02/15/2018 07:51 AM, Vladimir Sementsov-Ogievskiy wrote:
> > Minimal realization: only one extent in server answer is supported.
> > Flag NBD_CMD_FLAG_REQ_ONE is used to force this behavior.
> >
> > Tests 140, 147 and 205 are fixed due to now server failed on searching
> > export in context of NBD_OPT_SET_META_CONTEXT option negotiation.
> >
> > Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> > ---

[...]

> >   void nbd_client_detach_aio_context(BlockDriverState *bs)
> >   {
> >       NBDClientSession *client = nbd_get_client_session(bs);
> > @@ -828,6 +966,7 @@ int nbd_client_init(BlockDriverState *bs,
> >         client->info.request_sizes = true;
> >       client->info.structured_reply = true;
> > +    client->info.base_allocation = true;
>
> Hmm - the combination structured_reply = false and base_allocation = 
> true is bogus.  Then again, these two fields are in-out; left false 
> when handing over to the kernel NBD transmission phase (since the 
> kernel module does not yet support structured replies let alone block 
> status), and true when requested with qemu as the transmission driver 
> (since we want to use it if available).  I don't know if having a 
> single tri-state enum is any better than two bools (on input, it is 
> either all-or-none; on output, it is either none (old server), 
> structured reads only (qemu 2.11 server, for example), or all (this 
> series' server).


ohh, sorry for replying in so many emails.

about this: I'd prefer to leave it as is, and rethink (if needed) when 
implementing dirty-bitmaps context, because it's now obvious now, how it 
will be refactored for dirty bitmaps.



--
Best regards,
Vladimir