Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status

[Wouter Verhelst <w@uter.be>]

On Wed, Dec 14, 2016 at 06:51:48PM +0000, Alex Bligh wrote:
> 
> > On 14 Dec 2016, at 18:18, Alex Bligh <alex@alex.org.uk> wrote:
> > 
> > Let me have a go at a change.
> 
> OK I've pushed a change. I reordered a few bits (to put the
> base:allocation next to the stuff that talks about metadata
> queries at the start), but the main change is below.
> 
> -- 
> Alex Bligh
> 
> 
> 
> @@ -970,15 +1029,38 @@ of the newstyle negotiation.
>         - String, query to list a subset of the available metadata
>           contexts.
> 
> -    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`.
> -
>      For details on the query string, see under `NBD_OPT_SET_META_CONTEXT`.
> 
>      The server MUST either reply with an error (for instance `EINVAL`
>      if the option is not supported), or reply with a list of
>      `NBD_REP_META_CONTEXT` replies followed by `NBD_REP_ACK`.
> +
> +    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`, save that:
> +
> +    If one or more queries are sent, then the server MUST return
> +    those metadata contexts that are available to the client to
> +    select on the given export with `NBD_OPT_SET_META_CONTEXT`,
> +    and which match one or more of the queries given. The
> +    support of wildcarding within the leaf-name portion of
> +    the query string is dependent upon the namespace.
> +
> +    In either case, however:
> +
> +    * the server MAY return an incomplete list if returning a
> +      complete list would require undue resources.

This part is a bad idea, as per my other mail. Returning a complete list
should not be optional, but the definition of "complete" doesn't have to
imply "list all possible context names".

> +    * the server MAY return a context consisting of a namespace and
> +      a colon only (i.e. omitting the leaf-name) to indicate that
> +      the namespace contains a large number of possible contexts
> +      within that namespace (for instance a namespace `X-backup` with
> +      contexts that indicate whether blocks were written after
> +      a given date might accept queries of the form
> +      `'X-backup:modifiedtime>[unixdate]'` where `[unixdate]` is an
> +      arbitrary integer, and in this case it might simply
> +      return `X-backup:`)

This is way too detailed, I think. It should just allow namespaces to
define what _LIST_ may return, as long as the client is somehow able to
distill (through knowledge of the spec as well as the information sent
in reply to the _LIST_ command) all the metadata contexts it can
possibly select.

>      The metadata context ID in these replies is reserved and SHOULD be
>      set to zero; clients MUST disregard it.
> 
> @@ -1009,7 +1091,9 @@ of the newstyle negotiation.
> 
>      If zero queries are sent, the server MUST select no metadata contexts.
> 
> -    The server MUST reply with a number of `NBD_REP_META_CONTEXT`
> +    The server MAY return `NBD_REP_ERR_TOO_BIG` if a request
> +    seeks to select too many contexts. Otherwise
> +    the server MUST reply with a number of `NBD_REP_META_CONTEXT`

This part makes sense.

>      replies, one for each selected metadata context, each with a unique
>      metadata context ID, followed by `NBD_REP_ACK`. The metadata context
>      ID is transient and may vary across calls to `NBD_OPT_SET_META_CONTEXT`;

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12