Re: [Qemu-devel] [Nbd] [PATCH v5] doc: Add NBD_CMD_BLOCK_STATUS extension

[Stefan Hajnoczi]

On Tue, Dec 13, 2016 at 01:17:49PM +0100, Wouter Verhelst wrote:
> On Tue, Dec 13, 2016 at 10:37:00AM +0000, Stefan Hajnoczi wrote:
> > On Mon, Dec 12, 2016 at 09:43:13PM +0100, Wouter Verhelst wrote:
> > I'd prefer a programming model where the contexts don't need to be set
> > for the lifetime of the connection.  Instead the client passes a bitmap
> > (64-bits?) of contexts along with each BLOCK_STATUS command.  That way
> > the client can select contexts on a per-command basis.  It's unlikely
> > that more than 64 contexts need to be available at once but I admit it's
> > an arbitrary limitation...
> > 
> > I guess you've considered this model and decided it's better to
> > negotiate upfront, it's wasteful to enable multiple contexts and then
> > discard the response data on the client side because only a subset is
> > needed for this command invocation.
> 
> I do agree that it might be nice to be able to enable or disable
> particular metadata contexts for the lifetime of one BLOCK_STATUS
> command. However, the problem then becomes one of "where do we do that".
> The request header has a fixed size, and there is no space for such data
> in the request header. This could be worked around in ways that do not
> break compatibility with older implementations (not in the least because
> we're defining a new command that needs to be negotiated first, and so
> we could say that the server needs to understand a new request format),
> but I haven't found a way to do so that doesn't strike me as "very
> ugly".
> 
> In addition, most use cases that we've been presented with seem to
> require only one or (at most) a handful of metadata contexts. In that
> case, the ability to select which metadata contexts are to be used in
> transmission doesn't strike me as a very useful possibility, which would
> be used often. Given that, and given the problems described in the
> previous paragraph, I'm not convinced it's worth complicating things
> much over.
> 
> However, I could be convinced otherwise by strong arguments and by a
> suggested spec for how to pass the required information in a clean way.

Thanks for the responses, Woulter and Alex.

I don't have a strong argument for why context selection should be
per-command and you've explained that it would be awkward to add it to
the protocol.

Stefan

signature.asc
Description: PGP signature