Re: Selecting meta context when calling NBD_CMD_BLOCK_STATUS

[Wouter Verhelst]

On Thu, Dec 26, 2019 at 04:29:03PM +0200, Nir Soffer wrote:
> 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.

What is the problem with that?

ISTR that this issue was brought up when we defined the BLOCK_STATUS
command, but decided that (because the number of metadata contexts that
are likely to be in use during one session), the extra overhead from
having to parse more than one block status reply is not worth the
trouble of having to add the extra complexity to be able to filter it.

However, there might be something I'm missing.

> 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.

It doesn't actually require that, unless you need to be able to write
from multiple connections without breaking data consistency.

(I'm assuming that by "new handshake" you mean "another handshake on a
new connection", rather than the newstyle handshake; you *do* need the
newstyle handshake format to be able to get to NBD_OPT_SET_META_CONTEXT,
but that's a given)

[...]
> 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.

If we're going to do this, then I'd like to use a new command rather
than an "extend this command" flag. Otherwise you eventually end up with
wanting to extend a command another time, and thus something like
NBD_OPT_EXTENDED_EXTENDED_EXTENDED_COMMAND. Ugly.

Just make it something like NBD_OPT_BLOCK_STATUS_FILTERED or so, and then
add a NBD_CMD_BLOCK_STATUS_FILTERED. The current command would remain
(returning all metadata contexts), and the _FILTERED one would have the
command structure you're suggesting.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22