-
Notifications
You must be signed in to change notification settings - Fork 579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements for limactl prune, to not delete everything #1410
Comments
Here is my script to check what I currently have in the cache: #!/bin/sh
export LC_ALL=C
cache_dir=${XDG_CACHE_HOME:-$HOME/.cache}
for hash in "$cache_dir/lima/download/by-url-sha256/"*; do
echo "# $hash"
du -hs "$hash/data"* |
sed -e "s|$hash/data|$(cat "$hash/url")|"
done
echo "# $cache_dir/lima"
du -hs "$cache_dir/lima" | sed -e "s|$cache_dir/lima|total|"
|
As I replied in the #1409 my case is to cleanup downloads which are not used by existing VMs (like Everything which is not referenced by existing VM configs will be deleted with the implementation in #1409 (i.e. temporary files and obsolete versions of nerdctl are already covered there). |
Actually I was more thinking flags or additional options, not so much default behaviour (the suggested seems OK to me). Just that I sometimes delete the "default" VM instance to save some space, only to recreate it again some days later. |
A "--dry-run" option could also be useful, as it is now I never run Or maybe if it would prompt for confirmation before continuing, like |
Well.. your example with "default" makes some sense.. but I'd prefer to keep things simple.. i.e. either to implement this for all templates or do not implement this at all :) Dry run sounds like a good idea too.. I don't like prompts but lima is asking some confirmations already.. so might be better to follow the same behavior 🤔 |
I think your PR is an improvement, to the current command. Just was thinking if there could be others, too. Then again, I also wanted to cache packages and images to make it on par with vagrant and minikube... So don't want to complicate things, at least not needlessly. |
@AkihiroSuda proposed the following in the PR discussion
|
I would find this useful though:
For this reason it will become useful to copy your own templates into the I guess using a "keep only recently used templates" option would allow for more aggressive pruning, but maybe there should also be a way for the user to select which images to delete manually. Just show a list of all images and their sizes, and let them delete one at a time? For me personally the only pruning option I would use is "delete everything that is not used by the local templates or by a current instance". The "current instance" addition helps with images that are not created from a Footnotes
|
So after some thoughts I would suggest the following:
Questions:
|
JFYI I've updated the #1409 with ability to keep the template-referenced downloads too. |
Another concerning point are fallback images..
Considering this I'd change my mind to the "inverted" way ("prune everything except specified") maybe too.. |
I understood the suggestion to be about "usage" time, not "download". I'm not sure how you could actually implement this though. The closest I can think of is to keep a symlink in the instance directory back to the cache directory, and "touch" the cache directory every time you start/stop a VM, or any time you run Maybe that is overkill though; I can't tell though as I wouldn't be using time-based pruning myself.
It feels a bit weird to me though. It is the opposite of what It is also contrary to what "pruning" means: the selective trimming of dead or overgrown branches, not the total removal of the whole plant. |
So I wonder if this should instead have a special option to include them instead:
Fallback images would be identified as images in templates that don't specify a digest. |
Hmm.. this might work! TY for the suggestion 🤔 |
In the latest #1409 update I've simplified things and removed the prune subcommands. New CLI switches added instead:
|
How should flags combine?There are 2 obvious mechanisms: Flags create a union (combined via
|
Description
Can be good to keep some images around, for instance:
those that are "in use" by a currently running instance, even though the actual files have been copied from the cache
those that are referenced by the current version of a template, while pruning the old and obsolete earlier versions
When not removing the entire cache, maybe also remove:
temporary files (data.tmp) left by previous aborted downloads
obsolete versions of nerdctl-full, or other cached images/packages
Partial implementations:
The text was updated successfully, but these errors were encountered: