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.
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?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org