Quantcast
Channel: Debian User Forums
Viewing all articles
Browse latest Browse all 3567

Off-Topic • [Discussion] virt-sparsify return values?

$
0
0
They do different things.
They are not in the same category. Perhaps complimentary but not at all synonymous. rsysnc and compression utilities are operating at the file level, not on the disk, partition, or file system structure. Furthermore, the resulting image is directly usable - never needing to be restored, or uncompressed, and there is no source and destination with --in-place. The size of the image in the example is 997MB, in use it reports 3.2 used of 8.4GB.
In-place sparsification works using discard (a.k.a trim or unmap) support.
As I recall, and 'empty' disk with no file system is about 197k. Add a file system and the image size grows in proportion to disk size up to a few gigs with no files at all. The image compression operates on that structure. Add a large test file and delete it, virt-sparsify operates on that. This is the only way the reclaim used non-file space.

Sometimes extra operations are necessary outside the scope of file based utilities. Take a random disc, fill it half way - then delete the partition and make a new one half the original and fill it to half. Upon imaging will it be 25% the disk size, or 50%? It will be 50% without an extra zero-block step. Without that extra step the info in the deleted partition beyond the new partition is in fact recoverable, and still clogging up the works.
Isn't it just a certain number of seconds?
seconds? Possibly.
Maybe related, maybe not, during qemu-img copies from disk to image there is a similar digit added to the progress. Very clean and new the ending progress can be 100.0%. Known disk with issues I'll see 100.x% IIRC on one ntfs drive I saw that x number climb where I expected it to (at 35-40GB lets say) and the final was something odd like 100.13% That .13 means something! I suspect some retry count or error reporting. Both of these examples are just curiosities.

Let's see

Code:

$  virt-sparsify --machine-readable --in-place amd64_xfce_bees_2410-5_archive.qcow2[   2.3] Trimming /dev/sda1[   2.7] Sparsify in-place operation completed with no errors
It just drops the progress bar, so does notify-send! See, the numbers are different, and maybe took 2.3 seconds!?

Added, I updated my herder.tk;

Code:

grid [ttk::button .f1.nb.cow.btrim -text "trim" -width 4 -command {exec  virt-sparsify --machine-readable --in-place $basefile > ${tfs}/response; moO] -row 0 -column 2 -sticky wgrid [ttk::button .f1.nb.cow.barchive -text "archive" -width 7 -command {.f1.nb.cow.btrim invoke ; exec notify-send "[exec cat ${tfs}response]"; exec qemu-img convert -c -O qcow2 $basefile "$cowpath/${arch}_${dE}_${domain}_${versionN}_${eType}.qcow2"; lset basefile $cowpath/${arch}_${dE}_${domain}_${versionN}_${eType}.qcow2; newFile; .f1.nb.cow.binfo invoke; moO}] -row 0 -column 2 -sticky e}

Statistics: Posted by CwF — 2024-05-15 16:00 — Replies 3 — Views 82



Viewing all articles
Browse latest Browse all 3567

Trending Articles