https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
w
looks to be a thread on the topic at https://github.com/rancher-sandbox/rancher-desktop/issues/1942 and seems like trimming has been talked about in the limavm project, but looks like a non-trivial operation
b
Indeed...
So best solution is probably do the factory reset in your opinion?
w
thats the easiest since this stuff should be pretty ephemeral, but you can always dig around in lima to see if you can manually do it, but beware there be dragons
f
You can also manually delete image you don't need and/or run 
docker system prune
(use 
--all
option to delete images not currently in use).
Note that Rancher Desktop does 
trim
the disk. You need to run 
du
to see how much space the file actually takes, as it is a sparse file. 
ls -l
will show the allocated max size, but freed blocks are not actually in use.
Copy code
$ du -h ~/Library/Application\ Support/rancher-desktop/lima/0/diffdisk
2.1G	/Users/jan/Library/Application Support/rancher-desktop/lima/0/diffdisk
Of course a factory reset works too, but it is the nuclear option; it will delete all your images and containers and kubernetes objects.
We call 
fstrim
both during boot, and before shutting down the VM, but if you want to delete a bunch of images and release the space without restarting Rancher Desktop then you can also call it manually with 
rdctl shell sudo fstrim /mnt/data
w
Does the OS reclaim that space though from the diffdisk? Lots of time between those github issues so things i am sure have changed, but after releasing the blocks inside the instance there is always the desire to repack the sparse image and reclaim the space for the OS as well.
f
Yes, the space is returned to the OS. You don't need to repack the sparse image; 
fstrim
will release blocks and they will create holes in the sparse file when possible.
👍 1
w
cool so expectation is that should happen normally so anyone with a creeping diffdisk needs to do some image spring cleaning. helps me with a known good on expectations
f
You can test it by creating large files inside the VM (somewhere on 
/mnt/data
, not on the ramdisk), check the 
du
info on the host, and then delete the blocks and run 
fstrim /mnt/data
👍 1
Yes, 
docker system prune
is the obvious candidate; there are also buildkit caches etc that can be reclaimed
Note that tracking free space on macOS is somewhat challenging, as the OS also keeps hourly APFS snapshots for Time Machine. So stuff that is deleted may still hang around in a backup snapshot
But otherwise I think Rancher Desktop is pretty good on disk usage now (on macOS). Free space should be returned to the host OS, and RD snapshots use copy-on-write clones, so are almost instantaneous (except for the stopping and restarting of the VM) and only use up space once you modify the active volume. But any data shared with the snapshot will only be stored once.
👍 1
It is just confusing if you use 
ls -l
and see the large files. You have to use 
du
to see the actual usage, and even then you don't see how space may be shared with snapshot files. But that is the nature of modern file systems
Note that most of this is specific to macOS (and partially to Linux, especially on btrfs or XFS), but does not apply to Windows
204 Views
Open in Slack
PreviousNext
Powered by