[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Libguestfs] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAS
From: |
Wouter Verhelst |
Subject: |
Re: [Qemu-block] [Libguestfs] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO |
Date: |
Thu, 11 Apr 2019 22:02:08 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-block] [Libguestfs] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO,
Wouter Verhelst <=