On 22.06.20 19:44, Alberto Garcia wrote: > On Mon 22 Jun 2020 11:47:32 AM CEST, Max Reitz wrote: >>> I don't know the internals of qcow2 data_file, but are we really using >>> qcow2 metadata when accessing the data file? >> >> Yes. >> >>> This may have unwanted performance consequences. >> >> I don’t think so, because in practice normal lookups of L1/L2 mappings >> generally don’t cost that much performance. > > ...if the L2 cache size is large enough. Otherwise you need one extra > read operation to retrieve the L2 metadata. > > Possible performance problems when you have preallocation: > > - If a block hasn't been written yet (it's all zeroes) then you still > need to read the L2 entry and read the data block. If there is not > L2 table then you can simply return zeroes without going to disk at > all. This of course assumes that the contents of the unwritten data > block are zeroes. > > - QEMU still needs to read from disk (and cache in memory) the L2 > metadata, when it already knows in advance the contents of the L2 > entry (guest_offset == host_offset).
We could well optimize this regardless of preallocation. With data-file-raw, qemu doesn’t have to look at the L2 metadata at all. So the problem isn’t preallocation at all, it’s the fact that we don’t have such an optimization. But note that to implement such an optimization, we really do need preallocation: Because it would mean that we wouldn’t touch the L1/L2 tables for data-file-raw images during runtime, which would effectively make those images empty to today’s qemu versions. (OTOH, preallocation would then be pretty much superfluous for all newer versions of qemu. To address that, we could then add an incompatible version of data-file-raw. But I think we should only think about that once we get to that point.) You make a good point that data-file-raw was introduced alongside data-file. But, well. I personally can’t get myself to treating an autoclear flag like an incompatible one... Max
signature.asc
Description: OpenPGP digital signature
