On 8/23/19 9:40 AM, Eric Blake wrote: > Qemu was able to demonstrate that knowing whether a zero operation is > fast is useful when copying from one image to another: there is a > choice between bulk pre-zeroing and then revisiting the data sections > (fewer transactions, but depends on the zeroing to be fast), > vs. visiting every portion of the disk only once (more transactions, > but no time lost to duplicated I/O due to slow zeroes). As such, the > NBD protocol is adding an extension to allow clients to request fast > failure when zero is not efficient, from servers that advertise > support for the new flag. > > In nbdkit, start by plumbing a new .can_fast_zero through the backends > (although it stays 0 in this patch, later patches will actually expose > it to plugins and filters to override). Advertise the flag to the > client when the plugin provides a .can_fast_zero, and wire in passing > the flag down to .zero in the plugin. In turn, if the flag is set and > the implementation .zero fails with ENOTSUP/EOPNOTSUPP, we no longer > attempt the .pwrite fallback.
Based on our release plans,... > +++ b/docs/nbdkit-protocol.pod > @@ -173,6 +173,17 @@ This protocol extension allows a client to inform the > server about > intent to access a portion of the export, to allow the server an > opportunity to cache things appropriately. > > +=item C<NBD_CMD_FLAG_FAST_ZERO> > + > +Supported in nbdkit E<ge> 1.13.9. I'm changing this to nbkdit E<ge> 1.15.0 (ie. the first non-stable release after 1.14.0), with no plans to backport the feature to stable-1.14. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
