-
-No good protocol will add extensions without a reference
-implementation. And for qemu, the implementation for both server and
-client is quite simple, map a new flag in NBD to the existing qemu
-flag of BDRV_REQ_NO_FALLBACK, for both server and client; this will be
-landing in qemu 4.2. But at the same time, a single implementation,
-and unreleased at that, is hardly portable, so the NBD specification
-is reluctant to codify things without some interoperability testing.
-
-* Heading: Second implementation
-
-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), 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). Here, the power of filters stands out: by
-adding a second parameter to the existing 'nozero' filter, I could
-quickly change the behavior of any plugin on whether to advertise
-and/or honor the semantics of the new flag.
-
-* Heading: Show me the numbers
-
-When submitting the patches, a concrete example was easiest to prove
-the patch matters. So I set up a test-bed on a 100M image with every
-other megabyte being a hole:
-
-.sh file with setup, core function
-
-and with filters in place to artificially slow the image down (data
-writes slower than zeroes, and no data write larger than 256k, block
-status disabled) and observe behavior (log to see what the client
-requests based on handshake results, stats to get timing numbers for
-overall performance). Then by tweaking the 'nozero' filter
-parameters, I was able to recreate qemu 3.0 behavior (baseline
-straight copy), qemu 3.1 behavior (blind pre-zeroing pass with speedup
-or slowdown based on zeroing implementation), qemu 4.0 behavior (no
-speedups without detection of fast zero support, but at least nothing
-worse than baseline), and qemu 4.2 behavior (take advantage of
-pre-zeroing when it helps, while still nothing worse than baseline).
+- 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, 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:
+both fallocate(FALLOC_FL_ZERO_RANGE) and ioctl(BLKZEROOUT) can trigger
+fallbacks to slow writes, so we would need kernel support for new
+interfaces that guarantee fast failure.
+
+* segue: XXX
+slide 4800-? Or just sentence leading into Rich's demos?
+
+I just showed a case study of how nbdkit helped address a real-life
+optimization issue. Now let's see some of the more esoteric things
+that the NBD protocol makes possible.