[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Libguestfs] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO



Proposal looks good to me in principle.

On Fri, Mar 22, 2019 at 10:06:29PM +0000, Richard W.M. Jones wrote:
> However the original proposal you put here seems reasonable.  I have
> only one comment about it: Should the new error (ENOTSUP) be submitted
> as a separate patch to the spec?

I don't see the need? We don't need ENOTSUP for anything else right now;
our negotiation should cover all existing protocol options.

> On Fri, Mar 22, 2019 at 12:17:59PM -0500, Eric Blake wrote:
> > [1] https://lists.debian.org/nbd/2016/12/msg00015.html and following
> > (doc: Propose NBD_FLAG_INIT_ZEROES extension)
> > 
> > > 
> > > I will not push this without both:
> > > - a positive review (for example, we may decide that burning another
> > > NBD_FLAG_* is undesirable, and that we should instead have some sort
> > > of NBD_OPT_ handshake for determining when the server supports
> > > NBD_CMD_FLAG_FAST_ZERO)
> 
> From an implementation point of view I prefer simple flags over having
> to implement a brand new option.
> 
> We can always work out how to extend the flags field if we run out of
> flags.  For example, by implementing NBD_OPT_INFO2 with a much bigger
> flags field.

My plan has always been to reserve the most significant bit in the flags
field as a "there are more flags somewhere", and then add a 64-bit flag
field if we run out.

So yeah, I'm not too worried about running out of flags.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard


Reply to: