14.12.2016 19:38, Alex Bligh wrote:
Vladimir,
+non-zero number of metadata contexts during negotiation. Servers SHOULD
+reply to clients sending `NBD_CMD_BLOCK_STATUS without
backquote
Fixed
+ If zero queries are sent, then the server MUST return all
+ the metadata contexts it knows about.
I think that 'all .. it knows about' is too much. What about 'return all
available ..'? Anyway 'all ... it knows about' actually equals to 'all ... it
wants'. There may be some private, or unrelated contexts, for example..
This was not my wording, but I've changed it anyway to:
If zero queries are sent, then the server MUST return all
the metadata contexts that are available to the client to select
on the given export with `NBD_OPT_SET_META_CONTEXT`.
I think if they are available to select, we should list them. Thanks
also for reminding me to document why I put the export name into the
_LIST_ data (as it is for _SET_).
However, this raises another question. Wouter deliberately made the
query format freeform so that you could e.g. set a context like:
backup:modtime>201612081034
which might (in theory) return a list of blocks which are newer than
the given timestamp. It would clearly be impossible to return all such
contexts. I wonder if we should carve out an exception here.
Interesting. Even query 'backup:modtime>*' would be a problem, not only
empty query list.
Actually, we do not need to 'list contexts', as it is about management,
not about data transfer. We only need a way to check, that particular
query selects all needed contexts and no others. Just to be sure that we
are know, what we will select by NBD_OPT_SET_META_CONTEXT with _same_ query.
So, I suggest just to say, that _LIST_ can return error if too much
contexts are selected.|And same should be done for _SET_. And it should
be documented that this result of query (list or error) should be equal
for these two commands.
|
--
Best regards,
Vladimir
