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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
