6

I'm concerned about the ~/.cache directory for two reasons : it causes a lot of writes on my SSD unnecessarily, and it contains informations (like image thumbnails) about files in encrypted containers and external drives.

I put it in a tmpfs with a line in fstab. It runs without problems, until it becomes full : this causes error messages with some programs.

I assumed that the files in .cache were not supposed to be persistent (similarly to /tmp), which is why I used a tmpfs. So I wrote a script, run by cron, that cleans .cache each hour if the tmpfs is full.

But this causes an error message from tracker which can't find its database.

This leads me to wonder it this directory is really not supposed to be persistent. Is it a good idea to put it in a tmpfs ?

  • 2
    Note that data in tmpfs can still be written to swap. – Wyzard May 8 '16 at 10:16
  • I read that tmpfs is limited by default to half the size of the RAM, and therefore can't swap. Also, my system doesn't usually use a lot of RAM. – Arno May 8 '16 at 10:23
  • 2
    Your tmpfs may not be taking more than half your RAM by itself, but that doesn't prevent other programs from using more than half the RAM and pushing some tmpfs data out to swap. Also, data that hasn't been used in a long time may be proactively swapped, to free up RAM to be used as disk cache (which helps performance) and so that the RAM is quickly available if some other program needs it. – Wyzard May 8 '16 at 15:21
5

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).

Thesis

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.

  • I do very frequent backups on an external HDD, so data loss isn't a problem. I agree that wearing is not a big issue (it's a brand-new 500 GB Samsung SSD), but I wanted to avoid writing as much data on it if I can. I implemented your "whitelist" method before your post, and I think it's the best solution ; I will disable it if I notice a loss of performance or if I run into problems. For the moment, only the "tracker" and "borg" (for my backup software) directories are whitelisted and it runs fine. Thank you. – Arno May 9 '16 at 18:47
  • OK, I just saw a crash come from nowhere. No idead if there is a link, but I will keep the whole ~/.cache on my SSD just in case. – Arno May 9 '16 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.