50GB carved out disk file is surprising as a Docker Desktop user

[DavidSouther]

Coming from Docker Desktop, docker images prune is a reflex for low disk space in moderate to large build environments. In my case, my project has a Cargo/rust deps, Python, Node environments, and several container steps. Each of these create "lots" of ephemeral data, and regardless of workstation disk size require some cleaning every now and then. Every system has some form of "clean up your temp files" command, and after collecting and running all of them, the disk is usable again.

After switching to Finch, I was suprised that finch images -a prune claimed (and, to be fair, did) remove a bunch of images, but did not return any disk space. This is when I found out the finch VM's carved out 50GB disk. I understand that having that disk image and VM architecture provides many benefits in ability to deploy cross platform, and I probably could live with knowing the 50GB is forever claimed by finch for all time, and update my mental model of my laptop's file system to account for that.

But it would be very nice if Finch could find a way to reliably use Apple and Linux sparse files for its disc image :)

[pendo324]

Hi David. Finch does use a sparse disk for its persistent data volume in ~/.finch/.disks.

qcow2 files, supported by QEMU, properly show the allocated size when you run ls -h, but raw disk files (supported by QEMU and VZ) do not.

What's the output of du -h ~/.finch/.disks/<disk_name>?

[DavidSouther]

M1 Pro 32GB macOS 14.3 (23D56)

Finch uninstalled, no VM disk:

Finch installed, vm initialized:

du -h d0791de808fd746d
1.0G	d0791de808fd746d

Mid-sized image built:

finch build .
# oops no tag
finch build -t rustv1 .

finch images
REPOSITORY    TAG       IMAGE ID        CREATED               PLATFORM       SIZE       BLOB SIZE
<none>        <none>    932e76d53d49    About a minute ago    linux/arm64    1.9 GiB    625.0 MiB
rustv1        latest    932e76d53d49    6 seconds ago         linux/arm64    1.9 GiB    625.0 MiB

du -h ~/.finch/.disks/d0791de808fd746d
4.7G	/Users/dpsouth/.finch/.disks/d0791de808fd746d

Removed images:

finch rmi rustv1 932e76d53d49
finch images --all
REPOSITORY    TAG    IMAGE ID    CREATED    PLATFORM    SIZE    BLOB SIZE

du -h ~/.finch/.disks/d0791de808fd746d
4.7G	/Users/dpsouth/.finch/.disks/d0791de808fd746d

So while the disk is sparse & growing, it doesn't seem to shrink?

[pendo324]

Thanks for the detailed response!

Can you also try to run finch image prune and finch container prune? There might be some dangling data still being stored.

I'll try to repro on my side and see if there is any way to re-sparsify the disk

[DavidSouther]

% du -h ~/.finch/.disks/d0791de808fd746d
4.7G	/Users/dpsouth/.finch/.disks/d0791de808fd746d

% finch container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y

% finch ps -a
CONTAINER ID    IMAGE    COMMAND    CREATED    STATUS    PORTS    NAMES

% finch image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y

% du -h ~/.finch/.disks/d0791de808fd746d
4.7G	/Users/dpsouth/.finch/.disks/d0791de808fd746d

[Shubhranshu153]

The support for virt-sparsify/fstrim was added with lima-vm/lima#1102 (it doesnt run virt-sparsify/fstrim but supports discards)
Option1: The safest way would be to do at time time of boot, to run virt-sparsify/fstrim on boot.
Option2: Run virt-sparsify/fstrim dynamically from inside the vm while its running.

Both PoC were successful. Next steps would be to add add it to roadmap for implementation

Boot Script.

#!/bin/bash
mkdir -p /mnt/finch-lima
mount /dev/vdb1 /mnt/finch-lima
fstrim /mnt/finch-lima
umount /mnt/finch-lima
rm -rf /mnt/finch-lima

Result:

shubhum@147ddaa42911 .disks % du -chx -depth=1 ./
1.0G	./
1.0G	total
shubhum@147ddaa42911 .disks % du -chx -depth=1 ./
 13M	./
 13M	total
shubhum@147ddaa42911 .disks %