Re: [Libguestfs] [nbdkit PATCH] Update filters to support FUA flags.
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
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)