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

[Peter Lieven]

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 <address@hidden>
>> ---
> 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.

I meanwhile ran a short test which shows that there is potential for significant
improvement.

I created a 60GB qcow2 container and formatted it with ext4. To immediately 
show the difference
I disabled lazy inode table and lazy journal init (writing zero takes place 
immediately then).

Timing without the patch:
time mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/vda
real 1m5.649s
user 0m0.416s
sys  0m3.148s

Timing with the patch:
time mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/vdX
real 0m1.228s
user 0m0.116s
sys  0m0.732s

Container Size after Format without the patch: 1150615552 Byte (1097.3MB)
Container Size after Format with the patch: 24645632 Byte (23.5MB)

Peter


>
> Thanks,
> Fam