On 05/02/2018 09:37 AM, Max Reitz wrote:
On 2018-05-02 15:34, Ivan Ren wrote:
qemu-img info with a block device which has a qcow2 format always
return 0 for disk size, and this can not reflect the qcow2 size
and the used space of the block device. This patch return the
allocated size of qcow2 as the disk size.
I'm not quite sure whether you really need this information for block
devices (I tend to agree with Eric that wr_highest_cluster is the more
important information there), but I can imagine it just being nice to have.
Hmm, so in an extreme case, if you create an internal snapshot, then the
guest makes edits, then you remove the internal snapshot, we have a
wr_highest_offset that has advanced (because the guest changes had to
allocate new clusters due to COW of refcount=2 clusters); but the
deleted snapshot now means we have a lot of unused clusters earlier in
the image (deleting the snapshot took refcount=2 clusters back to 1, and
any COW'd clusters edited after the internal snapshot means the snapshot
version is now back to refcount=0, whether or not we also try to punch a
hole in the protocol layer for those freed clusters). Thus, reporting
the highest written cluster is a larger number than the number of
clusters that are actually in use, and both numbers might be useful to
know (how big do I have to size my block device, and how utilized is my
block device), especially if we add code for online compaction or
defragmentation of a qcow2 image so that we can move higher offsets into
holes left earlier in the image.
If you don't use internal snapshots, the only way to get holes of
unallocated clusters earlier in the image is if the guest uses TRIM
operations, and I'm not sure if that's easier or harder to trigger, nor
which approach (internal snapshots vs. guest TRIM operations) is likely
to leave more holes of unallocated clusters.
The whole implementation reminds me a lot of qcow2's check function,
which basically just recalculates the refcounts. So I'm wondering
whether you could just count how many clusters with non-0 refcount there
are and thus simplify the implementation dramatically.
We also recently added 'qemu-img measure', which DOES report how many
clusters are in use. Is any of that reusable here?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
