New answers tagged cache
There is /dev/shm, which is a RAM-backed filesystem. This isn't the same as caching as a cache means the file also resides on disk. With /dev/shm, which is a tmpfs filesystem, the files exist in memory only. Note that you can mount tmpfs volumes anywhere: mount -t tmpfs none /foo/bar There is just one usually mounted at /dev/shm.
After much research and reading this great article I found temporary solutions: decreasing net.ipv4.route.gc_timeout so the entries from cache get removed faster, and increasing net.ipv4.route.gc_interval so the garbage collector runs more often. But these are all temporary, since on our machine it only solved the problem for a few hours and more intensive ...
/var/cache is not a free-for-all like /var/tmp. Each service that requires it has a subdirectory in /var/cache with appropriate permissions for it to store files. On Debian and derived distributions, you can run dpkg -S /var/cache to find what packages have set up directories under /var/cache, and apt-get --reinstall install PACKAGE_NAME … to reinstall ...
Fortunately I still had a copy of the corrupted filesystem, so I had some idea of what should go in /var/cache for my system. cd /var/cache sudo mkdir apache2 apt ddclient debconf dictionaries-common fontconfig ldconfig man modsecurity sudo chmod a=,u=rwx ldconfig sudo chmod g=rsx man sudo chown man man sudo chown www-data modsecurity sudo mkdir ...
You can also use dmidecode. dmidecode -t cache should give you the info about the caches present and their individual sizes (also checkout the other options of dmidecode, a very useful tool).
You can't. There used to be a bdi_add_flusher_task() that got dropped around 2009 iirc. Also it was originally intended for filesystems but I don't think you're writing a filesystem :-) But.. I can't see why you would have 100% cpu, that doesn't make sense - unless you're doing 10+ GB/s writes to some fantastic $100,000 array. RAM is so much faster than ...
Top 50 recent answers are included