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
