Selecting meta context when calling NBD_CMD_BLOCK_STATUS

[Nir Soffer]

Currently client need to use NBD_OPT_SET_META_CONTEXT during handshake to
select the meta context it wants to get in NBD_CMD_BLOCK_STATUS.

This means that if you want to provide the option to get both
"base:allocation" and
"qemu:dirty-bitmap:x" using the same NBD client connection, you must
pay for getting
both during NBD_CMD_BLOCK_STATUS even if the user of the NBD client is not going
to use both.

Or, you can use new client connection for getting meta context not
that the current
client did not select, which require server that supports multiple
connections, and new
handshake. This seems to be more complicated than needed.

This complicates existing clients:
- qemu-img can return either "base:allocation" or
"qemu:dirty-bitmap:x" using complex
  undocumentde configuration
- ovirt-imageio is using dirty flag in the client to enable both
"base:allocation" and
  "qemu:dirty-bitmap:x", so we can provide merged extents reporting
both allocation
  status and "dirtiness" for every extent.

Should we extend NBD_CMD_BLOCK_STATUS so we can specify list of meta context
at the time of the call?

Looking at command structure, I don't think it could be extended. We
need to specify
list of 32 bit context ids, so we need something like:

32 bits, length of payload (N * 4)
32 bits, contex id 1
...
32 bits, context id N

But the length field of a BLOCK_STATUS command is already used to
specify the range
of the reply.

So maybe add a new handshake flag, NBD_OPT_EXTENDED_COMMAND. If set during
handshake, and NBD_FLAG_EXTENDED is set, a command will support
additional payload
like the list of context ids.

So a BLOCK_STATUS command will look like:

C: 32 bits, NBD_REQUEST_MAGIC)
C: 16 bits, NBD_FLAG_EXTENDED
C: 16 bits, NBD_CMD_BLOCK_STATUS
C: 64 bits, 42
C: 64 bits, 0
C: 32 bits, 1073741824
C: 32 bits: 4
C: 32 bit: 1

With this the server reply will be only for context id 1.

What do you think?

Nir