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 benchmark... (http://lists.nongnu.org/archive/html/qemu-block/2018-02/msg01166.html) 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. Max
Description: OpenPGP digital signature