virt-sparsify is a command used to shrink the size of virtual disk image files. It is essentially a trim operation performed on an inactive image.
It can also be used during an archival of a regular disk image. For that I don't have an example output, but it is essentially the same. First we'd qemu-img -convert from a real disc to a qcow2 file, then run virt-sparsify on the image, and lastly another qemu-img operation this time from qcow2 to qcow2 with the compression option enabled.
There is a difference in the feedback when doing images from different sources with differing amounts of runtime. The [ 7.2] and [ 7.7] values are what I'm wondering about. I have tried to look it up without much luck and lose interest after modern search and AI give me absolutely nothing of use.
7.x is rather high, I suppose. I have nothing to go on but suspicion. On a clean, unused golden image where the recent runtime is the time it takes to update minor things, and also run a package update and test - the number is usually in the 4's. I seem to remember that without something large like a kernel update the number may be in the 2's or lower. If this image is a disk from a machine with multiple updates, even a release upgrade, and more significant runtime the number may be 14+.
Also, multiple runs may possibly reduce from an initial higher to a subsequent run lower number. I'll get two postings of this result when processing a real disk into an archive with my herder.tk gui, and the sparsify result spit out through a notify-send bubble where the final output is a qemu-img info. Each time I see it change I wonder...
Anybody have a clue what those numbers are possibly reporting? My guess is some metric concerning freed space.
Code:
$ virt-sparsify --in-place amd64_xfce_bees_2410-5_archive.qcow2 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ --:--[ 7.2] Trimming /dev/sda1[ 7.7] Sparsify in-place operation completed with no errors]There is a difference in the feedback when doing images from different sources with differing amounts of runtime. The [ 7.2] and [ 7.7] values are what I'm wondering about. I have tried to look it up without much luck and lose interest after modern search and AI give me absolutely nothing of use.
7.x is rather high, I suppose. I have nothing to go on but suspicion. On a clean, unused golden image where the recent runtime is the time it takes to update minor things, and also run a package update and test - the number is usually in the 4's. I seem to remember that without something large like a kernel update the number may be in the 2's or lower. If this image is a disk from a machine with multiple updates, even a release upgrade, and more significant runtime the number may be 14+.
Also, multiple runs may possibly reduce from an initial higher to a subsequent run lower number. I'll get two postings of this result when processing a real disk into an archive with my herder.tk gui, and the sparsify result spit out through a notify-send bubble where the final output is a qemu-img info. Each time I see it change I wonder...
Anybody have a clue what those numbers are possibly reporting? My guess is some metric concerning freed space.
Statistics: Posted by CwF — 2024-05-15 01:58