Am 23.06.2020 um 09:28 hat Max Reitz geschrieben: > 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.
It depends. For reads, bypassing the L1/L2 tables is completely fine with data-file-raw. It may miss opportunities to optimise reading unallocated/zeroed clusters, but if the data file is actually sparse, it shouldn't make a big difference. Maybe we should just do this. For (potentially allocating) writes, you're right that we need to be more careful. If we want to completely bypass L1/L2 tables, preallocation is not enough, but we have to make sure that we never discard any clusters. Whatever we do for writes will be a non-trivial change. I wonder if it's really worth doing this for optimisation when nobody uses the feature yet anyway. > (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.) Well, if we create an incompatible version, we can have one that doesn't even store L1/L2 tables. Kevin
signature.asc
Description: PGP signature
