[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert

From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert
Date: Wed, 7 Mar 2018 18:11:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-07 17:33, Paolo Bonzini wrote:
> On 07/03/2018 16:57, Max Reitz wrote:
>>>>> (2) For sparse raw images, this is absolutely devastating.  Reading them
>>>>> now takes more than (ext4) or nearly (xfs) twice as much time as reading
>>>>> a fully allocated image.  So much for "if a filesystem driver has any
>>>>> sense".
>>> Are you sure that only the filesystem is the problem? Checking for every
>>> single byte of an image whether it is zero has to cost some performance.
>> Well, yes, but "read data location from FS metadata" + "realize it's a
>> hole" + memset() + "repe scasb" shouldn't take twice as much time as
>> "read data location from FS metadata" + "read data from SSD".
>> I expected the "realize it's a hole" part to fall out for free, so this
>> would that memset() + repe scasb take much longer than reading data from
>> the SSD -- and that's just pretty much impossible.
> This makes a lot of sense, but just to double-check, what does profiling
> say?

Oops, right.  I forgot that I forgot to drop the caches in that first

I don't have a full test run for this RFC version, but with the modified
series I hinted at in
http://lists.nongnu.org/archive/html/qemu-block/2018-03/msg00244.html I get:
- 0.6 s for a sparse qcow2
- 1.3 s for a preallocated qcow2 (basically like a sparse raw file in
this RFC here)
- 4.0 s for a fully allocated qcow2

So that makes more sense.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]