When a system have lots of I/O, trouble may arise. If an optical hard drive is über-solicited, quite easily you may get many kinds of failures, high CPU load, just because of I/O errors. In such case, using RAM as disk, aka RAM disk, may be a good option, as it allows way more I/O than an optical hard drive. Solid State Drive (SSD) addresses partly this issue, but it seems to, still, have way higher access time and latency than RAM. RAM disk, on the other hand, is non persistent (unlike SSD, though), quite an annoying drawback so even if you write some scripts to save data, you will loose some in case of power failure.
RAM disk is, actually, especially appropriate for temporary data, like /var/run, /var/lock or /tmp. Linux >= 2.4 supports tmpfs, some kind of RAM disk, that (as far I understand) does not reserve blocks of memory (meaning: it does not matter if you have a big tmpfs, unused memory in the tmpfs will still be available to the whole system).
Most of my computers have more than 1 Gb RAM. And, most of the time, they never use the Swap space. For instance (relevant lines are si and so, as swap in, swap out):
bender:$ vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 4146984 674704 1309432 0 0 6 9 3 34 2 1 97 0 nibbler:$ vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 862044 23944 84088 0 0 10 0 42 22 0 0 99 0 moe:$ vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 280552 166884 1297376 0 0 7 58 73 12 8 2 90 1
So they are good candidates to use tmpfs whenever possible. Do so with Debian GNU/Linux is fast-forward. Just edit /etc/default/rcS as follows (for /var/run & /var/lock):
RAMRUN=yes RAMLOCK=yes
and add, in /etc/fstab (for /tmp):
tmpfs /tmp tmpfs noexec 0 0
Next time you boot, diskfree should provide you with something like:
$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1033292 0 1033292 0% /lib/init/rw varrun 1033292 648 1032644 1% /var/run varlock 1033292 0 1033292 0% /var/lock tmpfs 1033292 4 1033288 1% /dev/shm tmpfs 1033292 0 1033292 0% /tmp
Update, questionable:
In Iceweasel/Firefox, to use tmpfs for caching data, on the page about:config, I added a new entry as follows:
browser.cache.disk.parent_directory | user set | string | /tmp/iceweasel-myusername
Somehow breaking LSB, on one box, I gave a try setting /var/tmp as tmpfs. Normally, /var/tmp content should not be erased on reboot. I considered writing a short script to save its data over reboot, however I assumed that copying stuff from and to /var/tmp on shutdown and boot could actually be slower than letting /var/tmp being reconstructed. I’ll need more input on this to estimate whether this is actually pertinent – so far, I can already tell KDE startup seems slower. Making so is just a matter of adding to /etc/fstab:
tmpfs /var/tmp tmpfs noexec 0 0
Update’s Update:
Having /var/tmp on tmpfs is a no go. Debian GNU/Linux use it properly, having its content rebuilt at each reboot is too slow and having its content in tmpfs is likely to fill it. I dropped this bad idea.
# cd /scratch 