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