Hi Kevin,
Thank you for your patience and explanations.
Thanks again!
Zhiyong
On 2/23/23 7:39 PM, Kevin Wolf wrote:
Am 23.02.2023 um 08:35 hat Zhiyong Ye geschrieben:
Hi Kevin,
Thank you for your reply and this method works.
May I ask if this 'image-end-offset' field can be shown in the qemu-img info
too? Because it is also a very useful information whether qcow2 is placed on
a file or a block device.
The only way to know the largest offset is by looking at all the
metadata in qcow2. 'qemu-img info' is supposed to be very fast, so we
don't do that there. 'qemu-img check' already looks at all metadata, so
we have the number readily available there.
Kevin
On 2/21/23 11:58 PM, Kevin Wolf wrote:
Am 21.02.2023 um 14:27 hat Zhiyong Ye geschrieben:
Hi Kevin,
Sorry to bother you again.
I intend to use this approach for snapshots of block devices, which, as you
say, requires a lot of disk space to store snapshot data. So, to save disk
space, after each successful external snapshot creation, I want to shrink
the block device that stores the backing_file image to the size that qcow2
data actually occupies, since it has become read-only. But there is no way
to get the actual size of qcow2 when it is stored in a block device.
Qemu-img info can easily get the actual size of qcow2 when it is stored in a
file using the fstat function, but this will fail and return 0 for block
devices. Therefore, it is necessary to implement the method of getting data
occupancy inside qcow2. I think there may be two possible ways to do this:
- Add a cluster count field @nb_clusters in the BDRVQcow2State for each new
cluster allocated and the actual size occupied by qcow2 is: nb_clusters *
cluster_size.
- Iterate through the refcount block to find the value with the largest host
offset, and this is the actual size occupied by qcow2.
Since I'm not very familiar with qcow2, may I ask if you have any advice on
getting the actual size when using qcow2?
I think what you need is the 'image-end-offset' field from 'qemu-img
check --output=json'.
Kevin
