On Mon, 17 Jun 2024 08:34:27 +0200 Johannes Schauer Marin Rodrigues wrote:

[...]
> as you suspected this is because of how sparse files work. Whenever you 
> upgrade
> something in your image, data gets deleted and new data gets added. The
> filesystem driver in the kernel does not zero-out those parts that it deletes
> and even if it would, qemu has no idea which blocks of the underlying image
> file it should now mark "sparse".
> 
> One tool that should reduce size again is e2image from e2fsprogs:
> 
>     $ e2image -rap old.img new.img
> 
> But this requires copying the actual file data.

Would that be quicker than regenerating the image from scratch?
Maybe, but, as you yourself note, it requires copying the data and then
removing the old image...

By the way, the .img file contains two partitions (the EFI system
partition and one ext2 partition): does e2image automatically handle
this mixed filesystem situation?

> I didn't try it out, but there
> is also the "discard" extended option of e2fsck:
> 
>     $ e2fsck -E discard your.img

Same question as above about the mixed filesystem.

> 
> Lastly, I do not know if the zerofree tool has support for sparse files? Maybe
> try running it on your FS and see what happens. :)

According to its description, zerofree is intended to be run from
GNU/Linux systems installed as guest OSes inside a virtual machine.
Hence, I should run from withing the QEMU VM.
Could you please tell me how to properly do that?
Would the following work well?

  $ sbuild-qemu-boot --boot=efi --read-write unstable-autopkgtest-amd64.img
  root@image # apt install zerofree

But then I should remount the root filesystem of the VM in read-only
mode, shouldn't I?
How can I do so _within_ the running VM?

What other tool should I use to shrink the image from the host system,
after running zerofree from the guest system?



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgpcUj5GUV_5s.pgp
Description: PGP signature

Reply via email to