[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