On Fri, 21 Jun 2024 00:42:21 +0200 Christian Kastner wrote: > Hi,
Hello Christian, nice to read you. Thanks for following up. > > On 2024-06-17 08:34, Johannes Schauer Marin Rodrigues wrote: > > Quoting Francesco Poli (wintermute) (2024-06-16 19:09:08) [...] > >> Now the allocated size is 832 MB, instead of 705 MB !!! > > In this particular case, one factor would be that the update caused new > APT lists to be downloaded, which have tens of MB. How so? As I said in the [original] bug report, I tried to run sbuild-qemu-update on the image that I had just regenerated from scratch. It seems that it found nothing to update, not even the APT repository lists (which were already up-to-date, as expected). Please take a look at the output of sbuild-qemu-update in the [original] bug report... [original]: <https://bugs.debian.org/1073509#5> [...] > I guess clever stuff could be done but honestly, it's probably simpler > to occasionally regenerate an image. It's clearly simpler to periodically regenerate the image and ditch the previous one, I agree. Simpler from the developer's standpoint, but less convenient from the user's standpoint. Come on, I am sure you are clever enough to figure out a good strategy to automatically prevent the image allocated size from growing indefinitely! I have faith in you! ;-) > > A hacky solution would be to use the --snapshot option to > sbuild-qemu-update on first run. In future runs, you could reset the > image to that snapshot using qemu-img. That would be a tradeoff though > as with time, updates would take longer and longer. [...] I think this strategy would make sbuild-qemu-update less and less useful: it would almost become more convenient to regenerate the image from scratch each time (or anyway, often) with mmdebstrap-autopkgtest-build-qemu ... I still hope that something can be implemented within sbuild-qemu-update, in order to "clean up" the unused blocks and allow the host system to see them as non-allocated in the sparse file. I guess I am not using the correct terms, due to plain ignorance, but I think you understand what I mean... -- 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
pgpPVqOhb1Mfi.pgp
Description: PGP signature
