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

Reply via email to