On 02/18/2016 02:18 AM, Roman Kagan wrote:
On Wed, Feb 17, 2016 at 01:58:47PM -0700, Eric Blake wrote:
On 02/17/2016 11:10 AM, Denis V. Lunev wrote:
@@ -446,6 +448,11 @@ The following request types exist:
about the contents of the export affected by this command,
until
overwriting it again with `NBD_CMD_WRITE`.
+* `NBD_CMD_WRITE_ZEROES` (6)
+
+ A request to write zeroes. The command is functional
equivalent of
+ the NBD_WRITE_COMMAND but without payload sent through the
channel.
This lets us push holes during writes. Do we have the converse
operation, that is, an easy way to query if a block of data will
read as
all zeroes, and therefore the client can bypass reading that
portion of
the disk (in other words, an equivalent to
lseek(SEEK_HOLE/SEEK_DATA))?
The spec doesn't have anything like that.
OTOH, unlike the write case, where you have all the information and
just
choose whether to send normal write or zero write, the extra round-trip
of a separate SEEK_HOLE/SEEK_DATA request may lead to actually
degrading
the overall throughput.
Rather it may be a better idea to add something like sparse read where
the server would, instead of sending the full length of data in the
response payload, send a smarter variable-length package with a
scatter-gather list or a bitmap of used blocks in the beginning, and
let
the client decode it and fill the gaps with zeros.
Sure, that would work too, and sounds nicer. Either way, the point is
that we should strongly consider improving the NBD protocol to allow
more efficient handling of sparse files, in both the push and in the
pull direction. Qemu already has a desire to use both directions of
improvements, but there are more programs, both clients and servers,
outside of qemu, that could benefit from such protocol improvements.