Sounds like you do have a problem
Yeah, so if the cache includes the tracker database, when you "clean" it you're just going to get it rebuilt again (after laboriously scanning all of your files). So I don't think this is a great idea.
The fundamental problem is that you have (a combination of) software writing to a limited filesystem, which doesn't observe the available space :(.
Thinking out loud
I believe Fedora used to manage
/tmp using tmpreaper, which deletes older files. In theory, some application developers might be have anticipated that model. In practice - people just don't do this to ~/.cache, so you're likely to hit some untested corner cases that blow up. E.g. I notice that
ls -l --time=atime ~/.cache/tracker shows a fair amount of variation, so I'm afraid that's not guaranteed to work nicely.
Much of the most important software will have some configurable limits. But it's not a great solution to have to go round configuring each one individually, allocating a fixed amount of the available space (or 0) for each one.
I guess it might be useful for web browsing, to allow e.g. 100M to make sure you avoid re-downloading very recent images and code. (Actually I suspect Firefox's default "automatic cache management" would avoid filling the filesystem itself).
You could have a separate tmpfs for a few "white-listed" pieces of software (using symlinks to redirect them), which you trust not to fill it / have allocated fixed space for, and let the others hit out of space errors (and get brutally cleaned by your existing system).
I suggest that if you can't afford the standard disk cache, then you do need to change to only supporting caching for selected software, and then just running damage limitation on everything else. "If" is the significant word here.
(Alternatively: if you use specific software that out-writes the most common software by significant factors, then maybe you're right and you need to contain that specific software).
Run the numbers. Is your SSD really in peril?
Ok, if we're talking about cheap netbooks with the smallest eMMC that can run Windows, then yes you are kinda screwed. You likely need to monitor your disk space usage, your software, limit and disable yourself. tmpfs might be a useful piece to contain some writes to disk cache, if you need to use this out-of-control (combination of?) software. But you need to be identifying the specific software.
However for the devices usually sold as "SSD" (and not "eMMC"), which currently start at 128-256GiB, the most common software will not cause any problem at all. If you want generic assurances about this backed by data, tests, trustworthy sources etc, Google is your friend - there's a whole bunch of fun articles. Personally I wanted to be able to monitor the use, to get a general idea. I think there's a few useful tools here.
- I used
tune2fs -l /dev/... to look at "Lifetime writes" on a given ext4 filesystem. Unfortunately btrfs doesn't seem to support this.
- On a running system, you can look at
/sys/block/<dev>/stat. The seventh column represents the number of 512-byte writes to the device. I suppose you could log this at regular intervals & in a shutdown script.
sudo atop can show disk writes per process, in disk mode. E.g. if you press "d", it will show cumulative writes per process since boot. For a few seconds, then it will change to showing the last interval. FIXME presumably there's a better way, e.g. to keep atop displaying the cumulative figure.
I ran a script using tune2fs under cron to append to a log file, and observed something like 1-4GB writes per day. This was higher than I really wanted to see, but was no problem for me given the rated lifetime writes of the drive. It should last well over a decade, at which point it'll be out of warranty and in want of replacement anyway. Even if you're not planning to replace before the drive goes out of warranty - the rated lifetime has to be conservative; it's not going to drop dead immediately. Tests have shown that drives can last many times longer than their rating.
And you do back up, right? You're not relying on a freak absence of hardware failures to ensure the survival of any critical data.