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