[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH 6/9] nbd: BLOCK_STATUS for standard get_block_st
Re: [Qemu-block] [PATCH 6/9] nbd: BLOCK_STATUS for standard get_block_status function: client part
Mon, 12 Mar 2018 12:48:07 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
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
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.