Re: [Qemu-devel] [RFC PATCH] block: optimize zero writes with bdrv_write_zeroes

[Fam Zheng <famz@redhat.com>]

On Sun, 02/23 20:10, Peter Lieven wrote:
> Am 22.02.2014 17:45, schrieb Fam Zheng:
> > On Sat, 02/22 14:00, Peter Lieven wrote:
> >> this patch tries to optimize zero write requests
> >> by automatically using bdrv_write_zeroes if it is
> >> supported by the format.
> >>
> >> i know that there is a lot of potential for discussion, but i would
> >> like to know what the others think.
> >>
> >> this should significantly speed up file system initialization and
> >> should speed zero write test used to test backend storage performance.
> >>
> >> the difference can simply be tested by e.g.
> >>
> >> dd if=/dev/zero of=/dev/vdX bs=1M
> >>
> >> Signed-off-by: Peter Lieven <pl@kamp.de>
> >> ---
> > With this patch, is is still possible to actually do zero fill? Prefill is
> > usually writing zeroes too, but according to the semantic, bdrv_write_zeroes
> > may just set L2 entry flag without allocating clusters, which won't satisfy
> > that.
> Can you specify which operation you exactly mean? I don't think that
> there is a problem, but maybe it would be better to add a check for
> bs->file != NULL so the optimization takes only place for the format
> not for the protocol.
> 

Previously, users can do

dd if=/dev/zero of=/dev/vdX

to force backend allocation and mapping. This is meaningful for later IO
performance, but how long the dd takes doesn't matter as much, since it is a
one time shot.

The same in your test case: yes, mkfs time may be improved, but it comes with
tradeoff with later IO's slowness: when the real user data comes, the allocation
still needs to be done.

I would do this in qcow2:

 1. In qcow2_co_writev, allocate cluster regardless of if data is zero or not.
 2. If data is zero, set QCOW2_OFLAG_ZERO in L2.

Fam