X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=2019-kvm-forum%2Fnotes-04-fast-zero;h=c818417d35f75bf9be8239c39a7314cf6d08f3b3;hb=6f34bcd5178f2622d9a15915ad2ca136525f318a;hp=989e8000ef4b1f8ae714631cc701fc7a757dc0e5;hpb=4365cf74d74623feee50020f8e1921028d13c444;p=libguestfs-talks.git

diff --git a/2019-kvm-forum/notes-04-fast-zero b/2019-kvm-forum/notes-04-fast-zero
index 989e800..c818417 100644
--- a/2019-kvm-forum/notes-04-fast-zero
+++ b/2019-kvm-forum/notes-04-fast-zero
@@ -53,15 +53,14 @@ didn't really help, for a couple of reasons.  If writing zeroes is
 fast, checking the destination first is either a mere tradeoff in
 commands (BLOCK_STATUS replacing WRITE_ZEROES when the destination is
 already zero) or a pessimization (BLOCK_STATUS still has to be
-followed by WRITE_ZEROES).  And if writing zeroes is slow, we have a
-speedup holes when BLOCK_STATUS itself is fast on pre-existing
-destination holes, but we encountered situations such as tmpfs that
-has a linear rather than constant-time lseek(SEEK_HOLE)
-implementation, where we ended up with quadratic behavior all due to
-BLOCK_STATUS calls.  Thus, for now, qemu-img convert does not use
-BLOCK_STATUS, and as mentioned earlier, I used the noextents filter in
-my test case to ensure BLOCK_STATUS is not interfering with timing
-results.
+followed by WRITE_ZEROES).  Conversely, if writing zeroes is slow, the
+penalty of the extra check when the destination is not a hole could be
+in the noise, but whether or not we have a definite speedup for
+avoiding WRITE_ZEROES depends on whether BLOCK_STATUS itself is fast -
+yet we encountered situations such as tmpfs that has a linear rather
+than constant-time lseek(SEEK_HOLE) implementation, where we ended up
+with quadratic behavior all due to BLOCK_STATUS calls.  Thus, for now,
+qemu-img convert does not use BLOCK_STATUS.
 
 * Heading: Pre-zeroing: a tale of two servers
 - 4400- .term
@@ -113,17 +112,18 @@ of the box.
 - 4700- nbdkit filters/plugins that were adjusted
 
 The qemu implementation was quite trivial (map the new NBD flag to the
-existing BDRV_REQ_NO_FALLBACK flag, in both client and server).  But
-to actually get the NBD extension into the protocol, it's better to
-prove that the extension will be interoperable with other NBD
-implementations.  So, the obvious second implementation is libnbd for
-a client (adding a new flag to nbd_zero, and support for mapping a new
-errno value, due out in 1.2), and nbdkit for a server (adding a new
-.can_fast_zero callback for plugins and filters, then methodically
-patching all in-tree files where it can be reasonably implemented,
-released in 1.14).  Among other things, the nbdkit changes to the
-nozero filter added the parameters I used in my demo for controlling
-whether to advertise and/or honor the semantics of the new flag.
+existing BDRV_REQ_NO_FALLBACK flag, in both client and server, due out
+in qemu 4.2).  But to actually get the NBD extension into the
+protocol, it's better to prove that the extension will be
+interoperable with other NBD implementations.  So, the obvious second
+implementation is libnbd for a client (adding a new flag to nbd_zero,
+and support for mapping a new errno value, due out in 1.2), and nbdkit
+for a server (adding a new .can_fast_zero callback for plugins and
+filters, then methodically patching all in-tree files where it can be
+reasonably implemented, due out in 1.16).  Among other things, the
+nbdkit changes to the nozero filter added the parameters I used in my
+demo for controlling whether to advertise and/or honor the semantics
+of the new flag.
 
 [if time:] Note that the file plugin was not touched in the initial
 patches. This is because accurate support is harder than it looks: