On 2024-06-22 12:49, Francesco Poli wrote: > On Fri, 21 Jun 2024 00:42:21 +0200 Christian Kastner wrote: >> 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...
Indeed. Sorry, I replied with gut instinct here. > 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! Apparently, there is a trick after all. (1) sbuild-qemu-{boot,update} need to add discard=unmap to the block device options of the image (2) In the guest, (2a) the root partition needs to be remounted with discard (2b) fstrim / (3) On the host, qemu-img convert -O qcow2 foo.img bar.img At least on my end, this reduced the image size. fstrim was the only solution I could find that could trigger TRIMs on a mounted filesystem. I've pushed a fix implementing this. It seems safe enough, though I wonder if I shouldn't have guarded this with a --shrink option. Best, Christian