On 3/8/19 7:48 AM, Richard W.M. Jones wrote: Quick thoughts for now; I'll probably have to spend more time on this over the weekend and reply with more details or ideas later. Agreed; pread should stay for simple, and a plugin/filter that supports structured reads should have a new set of callbacks. A while ago, we had a thread about split callbacks for better parallelism - where nbdkit calls the plugin to start a request (which returns control to nbdkit immediately), then the plugin calls a callback to complete the request. That may be worth adding now. For now, the NBD spec only supports 32-bit lengths on an extent; although there has been talk of how we would extend the protocol to allow the client to make 64-bit length requests (not for read or write, but definitely useful for flush, write zeros, block status); at which point, a 64-bit block status returning a 64-bit extent length makes sense. Perhaps we should require clients to use 64-bit lengths from the outset, in anticipation of NBD spec improvements? (but then nbdkit has to post-process those values down to a 32-bit result when talking to a client that did not negotiate 64-bit commands) Unless we support the REQ_ONE flag (where the client specifically wants only one extent returned). I'd go one step further - missing regions prior to a present region mean "hole"; missing regions after the last present region mean "no data available, don't advertise status to the client". This is because the NBD spec intentionally tries to allow both: - a server has more information available cheaply, allow it to return beyond the end so that a smart client can reduce the number of subsequent queries needed (a dumb client will ignore the extra data and probably query on the tail, but that doesn't hurt the server); but to avoid too much client confusion, any extra info reported has to be limited to a single extent, and coalesced with an extent that overlaps the guest's actual request - a server cannot cheaply obtain information over the entire length requested by the client, so it returns just an initial answer over the head, and the client has to ask again to find out about the tail The NBD spec also took care to require a successful return to make progress, so a client that wants to iterate over the entire export can write a sane loop (even if the client has to coalesce identical status in adjacent returns, it at least doesn't have to worry about getting stuck on an inf-loop for a 0-length return). REQ_ONE says that a successful answer has to be exactly one extent, covering only the head of the region. (That is, force the server to behave as if obtaining information beyond the first extent is expensive). It also tells the server that it must not report extra information beyond the initial request (because at least qemu 3.0 would assert that the server supplied too much information). You're also right that nbdkit can do REQ_ONE massaging, so whether we pass REQ_ONE on to the client or not makes it sound like the client needs a tri-state opt-in (no block status support, block status but let nbdkit handle REQ_ONE, block status and the plugin can handle REQ_ONE efficiently itself) Yep, and I think it needs to be tri-state, like can_fua, as argued above. file-plugin ? Not detecting allocated zeroes is okay; reporting the holes as zeroes is safe. Or take a leaf from the existing nozero-filter, where we default to maximum speed (no detection of allocated zeroes), but where a filter can be added that does read-based zero detection (slower, but potentially reports more zero blocks). Yeah, we'll have to think about every single filter, and whether it can even allow .can_extents, or must override the plugin. There's also an obvious use of the truncate-filter that treats the underlying plugin as fully allocated (if the plugin does not .can_extents), but where the truncated tail reports as sparse/zero. cache and cow filters need some thought. error needs a plan for whether we can inject errors on block_status requests, as well as consideration for whether it munges plugin extents based on current error policy. log needs a patch to log the new callback. Looking forward to seeing what you come up with, but it sounds like you are on track for supporting NBD_CMD_BLOCK_STATUS. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

On 3/11/19 2:44 PM, Richard W.M. Jones wrote: Seems like it would work. Still, I worry that some plugin might be doing some expensive work to compute a list of extents, only for nbdkit to throw that work away, vs. being able to accept a flag to know that nothing more than one extent will be used so the plugin might as well quit work early if it wants. Maybe we just document that we pass the flag through when the client requested it, but also permit the plugin to ignore the flag (plugins that care have the flag to optimize by, and plugins that don't care will not violate client expectations because nbdkit clamps the answer appropriately). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

On Tue, Mar 12, 2019 at 09:04:59AM +0100, Martin Kletzander wrote: We have can_* functions for most optional plugin features for a couple of reasons: (1) In non-C languages you can't just check the function pointer. (2) It's possible (in fact, quite likely) that a plugin could support extents only for certain disk images, but would always have an ‘extents’ function. As an example of (2), on Linux different filesystems have different levels of support for sparseness and sparse detection and so the nbdkit-file-plugin might implement ‘extents’ conditionally. As another example, a generalized "archive" plugin would support sparseness only for (say) tarballs but not for ZIP files. I think I'm going to pass the REQ_ONE flag to the plugin, but the plugin is free to either ignore it or implement it as an optimization. If the flag is present and the plugin returns more than one extent then nbdkit will determine the single extent to return. As a general approach we want plugins to be easy to write and for nbdkit to do the hard work when necessary. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html