On 04/04/2016 02:08 PM, Denis V. Lunev wrote:
This again makes me think this should be a different
command from something which is obviously useful and
comprehensible to more than one server/client (i.e.
allocation).
original design of this command has used 16 number
to specify the NUMBER of the bitmap which was
exported by the server.
The original design abused the 16-bit 'flags' field of each command to
instead try and treat that value as a bitmap number, instead of a
bitwise-or'd set of flags. That was one of the complaints against v1,
and was fixed in v2 by having a single boolean flag, NBD_CMD_FLAG_DIRTY,
which was off for (default) allocation queries, and set for dirtiness
queries. We can add other flags for any other type of queries, and the
principle of each query being a run-length-encoded listing still applies.
We have reserved number 0 for 'used' bitmap, i.e.
bitmap of allocated blocks and number 1 for 'dirty'
bitmap. Though we can skip specification of the
belonging of any number except '0' and put them
to server-client negotiations. Or we could reserve
'1' for dirtiness state as server-client agrees and
allow other applications to register their own bitmaps
as the deserve to.
Why not to do things this original way?
If you want to encode particular ids, you should do so in a separate
field, and not overload the 'flags' field.
As it is, we don't have structured writes - right now, you can write a
wire sniffer for the client side, where all commands except
NBD_CMD_WRITE are fixed size, and NBD_CMD_WRITE describes its own size
via its length field; the extension NBD_CMD_WRITE_ZEROES still fits into
this scheme. All NBD implementations have to supply NBD_CMD_WRITE, but
any extension commands do NOT have to be universal. Writing a wire
sniffer that special-cases NBD_CMD_WRITE is easy (since that command
will always exist), but writing a wire sniffer that special-cases
arbitrary commands, particularly where those arbitrary commands do not
also self-describe the length of the command, is hard. We can't
overload the flags field to say which bitmap id to grab, but we also
can't arbitrarily add 4 bytes to the command size when the command is
NBD_CMD_BLOCK_STATUS (because wire sniffers that don't know about
NBD_CMD_BLOCK_STATUS wouldn't know to expect those four bytes to be part
of the current packet rather than starting a new packet).
The recent work on structured reads made it possible for an arbitrary
wire sniffer to gracefully skip over the variable-length return size
reply to NBD_CMD_BLOCK_STATUS, and any other extension command that we
might add later. But right now, I'm not seeing a compelling reason to
add structured commands to the NBD protocol.