[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert |
Date: |
Wed, 7 Mar 2018 17:33:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
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?
Paolo