[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Nbd] [PATCH] Strawman proposal for NBD structured repl
From: |
Wouter Verhelst |
Subject: |
Re: [Qemu-devel] [Nbd] [PATCH] Strawman proposal for NBD structured replies |
Date: |
Tue, 29 Mar 2016 22:57:35 +0200 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Tue, Mar 29, 2016 at 09:39:43PM +0100, Alex Bligh wrote:
> Here's a strawman for the structured reply section. I haven't
> covered negotation.
LGTM, for the most part.
[...]
> +Each chunk consists of the following:
> +
> +S: 32 bits, 0x668e33ef, magic (`NBD_STRUCTURED_REPLY_MAGIC`)
> +S: 32 bits, flags (including type)
> +S: 64 bits, handle
> +S: 32 bits, payload length
> +S: (*length* bytes of payload data)
> +
> +The flags have the following meanings:
> +
> +* bits 0-7: `NBD_CHUNKTYPE`, an 8 bit unsigned integer
> +* bits 8-31: reserved (server MUST set these to zero)
I understand why you do it this way (we don't need 2^16 reply types),
but (in contrast to the flags in the request packet) this makes it
harder to specify flags and command type as separate fields (there is no
24-bit integer on most systems).
As said though, I understand why, and the alternative isn't ideal.
[...]
> +If the server detects an error during an operation which it
> +is serving with a structured reply, it MUST complete
> +the transmission of the current data chunk if transmission
> +has started (by padding the current chunk with data
> +which MUST be zero), after which zero or more other
> +data chunks may be sent, followed by an `NBD_CHUNKTYPE_END`
> +chunk. The server MAY set the offset within `NBD_CHUNKTYPE_END`
> +to the offset of the error; if so, this MUST be within the
> +length requested.
This should probably also be more explicit about what to do if the
server doesn't want to set the offset (set it to zero, presumably)
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12