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
