[Libguestfs] [nbdkit PATCH] Update filters to support FUA flags.

[Eric Blake]

On 01/19/2018 11:04 AM, Richard W.M. Jones wrote:
> On Fri, Jan 19, 2018 at 10:45:51AM -0600, Eric Blake wrote:
>> I'm wondering if we're missing documentation here (and/or in the plugins
>> document) that if .can_write returns true, the plugin must supply a
>> .pwrite; likewise for .can_trim implying a .trim, and .can_flush
>> implying a .flush.
> 
> It's a strange one.
> 
> For example if a plugin returns .can_pwrite == 1 but doesn't implement
> .pwrite then the NBD connection will appear to be writable, but any
> attempt to write will return EROFS.
> 
> On the other hand (a) plugins don't usually implement can_write
> because the "autosensing" usually works, and (b) it doesn't crash or
> do anything particularly bad.
> 
> can_trim/trim and can_flush/flush are similar.
> 
> However unfortunately src/plugins.c now assert-fails if the FUA flag
> is present but plugin.flush does not exist.  Is this a bug?

I hope not.  connections.c passes the FUA flag down to the backend only
if .can_flush (soon to be .can_fua) returned true; otherwise, it never
advertised FUA to the client and so rejects the request up-front with
EINVAL because the client requested the use of a flag that the protocol
did not permit.  Thus, FUA should never reach the backend in plugins.c
unless there is an implementation for it, unless we have a buggy filter
in between (and an assert is appropriate for diagnosing a buggy filter,
since I'm trying to document the additional restrictions that filters
must abide by, which include never sending FUA to next_ops->func if
next_ops->can_fua didn't return true).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180119/6f016432/attachment.sig>