[Libguestfs] [nbdkit PATCH 2/5] protocol: Validate request flags

Richard W.M. Jones rjones at redhat.com
Thu Jan 26 10:18:52 UTC 2017


On Wed, Jan 25, 2017 at 08:55:18PM -0600, Eric Blake wrote:
> On 01/20/2017 02:16 PM, Eric Blake wrote:
> > Reject rather than silently ignoring unknown client request flags.
> > 
> 
> > 
> > +  /* Validate flags */
> > +  if (flags & ~NBD_CMD_FLAG_FUA) {
> > +    nbdkit_error ("invalid request: unknown flag (0x%x)", flags);
> > +    *error = EINVAL;
> > +    return 0;
> > +  }
> 
> Right now, our NBD_CMD_FLAG_FUA implementation causes a full flush
> action from the plugin, even if it is possible to write a client that
> knows how to preserve FUA semantics in a lighter-weight manner than a
> full fdatasync().  In other words, it obeys the semantics required by
> the NBD protocol, but not necessarily in the most optimum way.

Does NBD (protocol) now support a more fine-grained flush?

> Unfortunately, the callback interfaces for a plugin do not have any way
> to pass flags from the client to the plugin (other than my new .zero
> callback, but right now it only supports a single may_trim argument used
> as a boolean, rather than an actual int flags argument).  Do we want or
> need to enhance the set of callback interfaces to allow plugins that can
> act on flag values, rather than always implementing fua semantics
> ourselves by the heavy-weight .flush call?

Can we add a flush2 method which adds flags?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html




More information about the Libguestfs mailing list