From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHStZ-0001jq-AC for qemu-devel@nongnu.org; Thu, 15 Dec 2016 05:04:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHStW-0005Xf-6G for qemu-devel@nongnu.org; Thu, 15 Dec 2016 05:04:13 -0500 Received: from mail.avalus.com ([89.16.176.221]:49396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHStV-0005XJ-Qe for qemu-devel@nongnu.org; Thu, 15 Dec 2016 05:04:10 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alex Bligh In-Reply-To: <20161214201858.lblzw2ayddidxfyp@grep.be> Date: Thu, 15 Dec 2016 10:04:05 +0000 Content-Transfer-Encoding: 7bit Message-Id: <58F412AB-8A4C-403F-AEE2-D2FB958D447A@alex.org.uk> References: <20161214150840.10899-1-alex@alex.org.uk> <31576d46-c0ed-29b9-71a0-5aca1790799a@virtuozzo.com> <6D1B30FC-FD7E-474C-A8E3-FD87E7AA1364@alex.org.uk> <5e9150ed-2127-f2e8-f9db-a514e8f0ddf8@virtuozzo.com> <5E697C22-5FBB-49A2-A018-A6B96E29FE84@alex.org.uk> <94ef3ef2-b76f-fa5d-cbaf-8990ce2b1be8@virtuozzo.com> <20161214181323.mehzfmlf6z4pyajp@grep.be> <3D392E31-DDA4-4316-B26D-871E94A83935@alex.org.uk> <20161214201858.lblzw2ayddidxfyp@grep.be> Subject: Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst Cc: Alex Bligh , "nbd-general@lists.sourceforge.net" , Kevin Wolf , Vladimir Sementsov-Ogievskiy , "Stefan stefanha@redhat. com" , "qemu-devel@nongnu.org" , Paolo Bonzini , "Denis V . Lunev" , John Snow > On 14 Dec 2016, at 20:18, Wouter Verhelst wrote: > >> + * 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. OK, this part now reads: 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, for any given namespace the server MAY, instead of exhaustively listing every matching context available to select (or every context available to select where no query is given), send sufficient context records back to allow a client with knowledge of the namespace to select any context. Each namespace returned MUST still satisfy the rules for namespaces (i.e. they must begin with the relevant namespace, followed by a colon, then printable non-whitespace UTF-8 characters, with the entire string not exceeding 255 bytes). This may be helpful where a client can construct algorithmic queries. For instance, a client might reply simply with the namespace with no leaf-name (e.g. 'X-FooBar:') or with a range of values (e.g. 'X-ModifiedDate:20160310-20161214'). The semantics of such a reply are a matter for the definition of the namespace. Hope that works. -- Alex Bligh