On Mon, Jan 15, 2018 at 10:55:04AM -0600, Eric Blake wrote:
On 01/14/2018 06:11 AM, Richard W.M. Jones wrote:
This patch isn't complete (patch 6/6 isn't finished) so it's just for discussion, although it does compile and run.
This introduces to nbdkit a concept of "filters" which can be placed in front of plugins to modify their behaviour. Some examples where you might use filters:
* Serve a subset of the data, such as (offset, range) or a single partition from a disk image.
* Inject delays or errors for testing clients.
* Implement "copy-on-write" (a feature found in other NBD servers).
How hard would it be to allow filters to control what features are advertised? For example, we've already proven that it is easy to expose features to the end client that are not present in the plugin (we advertise FUA support to end clients, because we can emulate it by calling the plugin's .flush at the right places; we also advertise write zero support because we can call the plugin's .pwrite as a fallback).
I feel that the right way for us to support FUA is going to involve having a new .pwrite call with the additional flag, and I think we also will need a ‘.can_fua’ method so we don't need to overload can_flush as we do now. In that case any filter can simply overload those methods and modify it (in either direction, either adding or removing). Rich.
But for testing purposes, it might be nice to permit the reverse: intentionally filter out a feature that the plugin supports, but which we do not want to advertise to the end client, for the purposes of testing the client's ability to fall back to other means in the absence of that feature.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org