On 6/10/19 6:00 PM, Gary Dale wrote:
Any ideas on what I'm doing wrong?
Do you know for sure whether you have internal or external snapshots?
And at this point, your questions are starting to wander more into
libvirt territory.
Yes. I'm using internal snapshots. From your other e-mail, I gather that
the (only) benefit to blockcommit with internal snapshots would be to
reduce the size of the various tables recording changed blocks. Without
a blockcommit, the L1 tables get progressively larger over time since
they record all changes to the base file. Eventually the snapshots could
become larger than the base image if I don't do a blockcommit.
Not quite. Blockcommit requires external images. It says to take this
image chain:
base <- active
and change it into this shorter chain:
base
by moving the cluster from active into base. There is no such thing as
blockcommit on internal snapshots, because you don't have any backing
file to push into.
With internal snapshots, the longer an L1 table is active, the more
clusters you have to change compared to what was the case before the
snapshot was created - every time you change an existing cluster, the
refcount on the old cluster decreases and the change gets written into a
new cluster with refcount 1. Yes, you can reach the point where there
are more clusters with refcount 1 associated with your current L1 table
than there are clusters with refcount > 1 that are shared with one or
more previous internal snapshots. But they are not recording a change to
the base file, rather, they are recording the current state of the file
where an internal snapshot says to not forget the old state of the file.
And yes, a qcow2 file with internal snapshots can require more disk
space than the amount of space exposed to the guest. But that's true
too with external snapshots (the sum of the space required by all images
in the chain may be larger than the space visible to the guest).