Hi again, Quoting Johannes Schauer Marin Rodrigues (2024-06-17 08:34:27) > Quoting Francesco Poli (wintermute) (2024-06-16 19:09:08) > > But, the allocated size has significantly grown: > > > > $ cd ~/.cache/sbuild/ > > $ ls -altrFs --si > > total 4.4G > > 4.1k drwx------ 37 $USER $USER 4.1k May 4 16:03 ../ > > 4.1k drwxrwx--- 2 $USER $USER 4.1k May 13 23:19 build/ > > 3.6G -rw-rw---- 1 $USER $USER 27G Jun 9 22:00 > > OLD_unstable-autopkgtest-amd64.img > > 4.1k drwxrwx--- 3 $USER $USER 4.1k Jun 16 18:26 ./ > > 832M -rw-rw---- 1 $USER $USER 27G Jun 16 18:26 > > unstable-autopkgtest-amd64.img > > > > Now the allocated size is 832 MB, instead of 705 MB !!! > > That could explain how I had reached 3.6 GB, one run of sbuild-qemu-update > > after the other... > > > > But why does the allocated size increase? > > Maybe there's something about sparse file support that I do not > > fully understand. > > > > Is there anything that can be done inside sbuild-qemu-update to prevent > > the allocated size from growing indefinitely? > > Apart from periodically regenerating the image from scratch, I mean... > > 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. I didn't try it out, but there > is also the "discard" extended option of e2fsck: > > $ e2fsck -E discard your.img > > 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. :)
follow-up question: are you on bookworm or on trixie? If the latter, would you mind testing an improved version of mmdebstrap-autopkgtest-build-qemu which is able to create bit-by-bit identical disk images? Thanks! cheers, josch
signature.asc
Description: signature
