On Tue 07 Mar 2017 11:36:54 AM CET, Daniel P. Berrange wrote: >> The creation scenario is: >> >> $ qemu-img max-size -O qcow2 --size 5G >> 196688 > > Hmm, so that appears to be indicating the amount of physical space > that a qcow2 image would take up before any data has been written to > it. > > That's not actually what I was thinking. I would like to know the > maximum possible physical space that a 5G qcow2 image would take up > once data is written to every sector. Obviously this is impossible to > say if you allow for internal snapshots, but I think it is fine to say > that we ignore internal snapshots for purposes of this command.
We have clearly two different use cases here, although I wonder how useful the one that you are describing is. After all the maximum size of a fully allocated imaged is always going to be the virtual size plus a small overhead for the metadata. I haven't made the numbers for all cases, but I'll take the risk and say it's always going to be really small (the 10% you use to illustrate your point is way too much). A fully allocated 1TB qcow2 image needs less than 200MB of metadata (that's 0.02% of the total size). If we reduce the cluster size to its minimum (512 bytes) then it's around 20GB (still ~2% of the total size). Computing the size that you need to convert the data that is currently allocated is a different matter, because it depends a lot on the scenario: whether you are using preallocation, or you have backing images, etc. Berto
