From: Kevin Wolf <kwolf@redhat.com>
To: Zhiyong Ye <yezhiyong@bytedance.com>
Cc: mreitz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: Questions about how block devices use snapshots
Date: Tue, 21 Feb 2023 16:58:44 +0100 [thread overview]
Message-ID: <Y/TqNIz9EEXaop/Q@redhat.com> (raw)
In-Reply-To: <12bfc9a0-45e0-21f2-3d50-988ea2ad80c8@bytedance.com>
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
next prev parent reply other threads:[~2023-02-21 15:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 12:45 Questions about how block devices use snapshots Zhiyong Ye
2023-01-09 13:57 ` Kevin Wolf
2023-01-11 7:55 ` Zhiyong Ye
2023-01-11 14:32 ` Kevin Wolf
2023-01-11 16:21 ` Zhiyong Ye
2023-01-12 11:47 ` Kevin Wolf
2023-01-13 8:30 ` Zhiyong Ye
2023-02-21 13:27 ` Zhiyong Ye
2023-02-21 15:58 ` Kevin Wolf [this message]
2023-02-23 7:35 ` Zhiyong Ye
2023-02-23 11:39 ` Kevin Wolf
2023-02-23 11:47 ` Zhiyong Ye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/TqNIz9EEXaop/Q@redhat.com \
--to=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=yezhiyong@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.