Re: [Qemu-devel] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]

On 04/04/2016 08:47 AM, Denis V. Lunev wrote:
> On 04/04/2016 05:15 PM, Eric Blake wrote:
>> qemu already has an existing server implementation option that will
>> explicitly search the payload of NBD_CMD_WRITE for large blocks of
>> zeroes, and punch holes in the underlying file.  For old clients
>> that don't know how to use the new NBD_CMD_WRITE_ZEROES, this is a
>> workaround to keep the server's destination file approximately as
>> sparse as the client's source.  However, for new clients that know
>> how to explicitly request holes, it is unnecessary overhead; and
>> can lead to the server punching a hole and risking fragmentation or
>> future ENOSPC even when the client explicitly wanted to write
>> zeroes rather than a hole.  So it makes sense to let the new
>> NBD_CMD_FLAG_NO_HOLE work for WRITE as well as WRITE_ZEROES.
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
> 
> what behaviour do you expect  for QCOW2 file?
> We should fully provision that image as far as I could understand,
> i.e. allocate data blocks with zero content.

For an old client (that doesn't know how to use WRITE_ZEROES), the
client will send ALL data via CMD_WRITE; and then the server pays
attention to its command-line flags on whether to parse for zeroes
(which is already tri-state, between always allocate, use WRITE_SAME
where possible, and TRIM where possible).  The result is that the server
can be commanded at startup to make its file sparse, even when the
client did not have a sparse file to start with.

For a new client, the client will always use WRITE_ZEROES when it is
okay with the server punching holes, and WRITE_ZEROES+NO_HOLE when it
wants to compress the network stream but still force allocation.
Therefore, the server spending time looking for zeroes during WRITE is
wasted effort, and the client should always send WRITE+NO_HOLE for data
that is not a hole on the client's side of things (even if that content
is all zeroes).  The result is that the server can now create a file
with the same sparseness pattern as the client, assuming that client and
server have the same granularity of hole sizing.

With a qcow2 file as the underlying file of the qemu nbd server, the
behavior then depends on whether the qcow2 file is version 2 (no
efficient ways to represent all zeroes, but there ARE some shortcuts
that can be taken when you know the file is backed by something else
that is all zero) or version 3 (where there is an explicit and efficient
way to mark an all-zero cluster).

> 
> I think that this would work.
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]