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).
But as you say:
> Sure, it’s not free. But if we decide we should indeed fully ignore
> the L1/L2 tables for data-file-raw images, the qcow2 spec must be
> amended. As I can read it, it currently doesn’t say so.
>
> (By the way, this is not a trivial change. Right now, data-file-raw
> is an autoclear flag: If a version of qemu that doesn’t support it
> accesses the image, it will automatically clear the flag, but the
> image stays valid. If we decide to completely ignore the L1/L2 tables
> (i.e. not even create them), then this can no longer be an autoclear
> flag. We’d need a new incompatible flag. (Because without L1/L2
> tables, the image becomes useless to older qemu versions.))
Berto
