Alt TextA screenshot of a file manager preview window for my ~/.cache folder, which takes up 164.3 GiB and has 246,049 files and 15,126 folders. The folder was first created about 1.75 years ago with my system
seems like a bug in one of rhe programs you’re using.
modt software automatically manages it’s cache…
are you using build caching tools such as Mozilla sccache? These tend to create 20gb+ cache directories, especially if used with debug builds
I just map both the user cache and the /tmp directory to a RAM drive. I allocated 4 GB but in practice it never gets even close to that much, and Linux seems to not be reserving the entire 4 GB at boot so I would assume how much RAM is used depends on how much is actually in your cache.
It also defers cache and tempfile related problems to turning it off and on again.
13,574 totaling 1.7gb, not too bad. Hey OP how do you get to this view? It looks like we both use nautilus but when I select “properties” on the .cache folder it looks different.
I use thunar (with ePapirus-Dark icons which is probably what makes it look like nautilus), I liked nautilus when I used it but thunar has a bit more functionality that I like
It’s yay, which took up ~160 GiB. It was storing previous versions of AUR binaries which I guess added up over time. I posted a screenshot of ncdu outputs for a more detailed breakdown in one of the other reply threads
Honestly the reason I’ve put yay/paru’s build directory into ram/tmpfs long ago. It’s almost never worth it keeping all those packages checked out. You also do your ssd a favour by not hammering it with compile workloads.
You don’t have to clean your ~/.cache every now and then. You have to figure out which program eats so much space there, ensure that it is not misconfigured and file a bugreport.
<span style="color:#323232;">% du -sh ~/.cache
</span><span style="color:#323232;">1,6G /home/bizdelnick/.cache
</span>
I don’t remember if I ever cleaned it up. Probably a couple years ago when I moved my old HDD to new PC with freshly installed OS. It does not grow accidentally. Only in some very rare cases. As well as some other dirs under ~ and var. If it is a critical system, set up monitoring of free filesystem space. If not, you will notice if it becomes full (I can’t remember when this happened to me last time, maybe ~15 years ago when some log file started to grow because of endless error messages).
Because some users experienced accidential grows like OP had 160 Gbyte. So general advice for linux users can be stated as: Check your ~/.cache every now and then
Critical systems/servers shall better be monitored as you suggest.
Some users experienced accidential growth of /var/log. Some users experienced accidential growth of /var/cache. Some users experienced accidential growth of /var/lib. Some users experienced accidential growth of ~/.xsession-errors. Shall I continue?
Does every user need to begin his day checking all that places? No, he does not. It is waste of time. Such situations are extremely rare. If you are paranoid, check df to see if you have enough free space, and only if it unpredictably shrinked begin to ivestigate which directory has grown.
I don’t get your point. Why should somebody do this every day?
As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder. So checking it from time to time is a good advice. If we all do this for a time, and create bug tickets for software which is not cleaning up. Then this problem will hopefully go away with future software releases.
As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder.
It is the first thread about overgrown ~/.cache directory I see since I use Linux (~16 years or so). But, as I wrote above, this sometimes (rarely) happens with log files and some other directories. Checking each of them is a waste of time, if not automated, checking just one or few of them makes sense only if you are testing some app and looking for files it creates.
Add comment