Limit noise from hard disk using RAM (tmpfs) instead

I’m using a laptop, among other things, as alarm clock (included in my -utils general debian package). The hard disk of this laptop is not getting any younger and get noisy while there’s a decent amount of RAM available.

I toyed a bit in the past with ramdisk/tmpfs (the later having the benefit not to used a real fixed size but to adjust and unused memory free) and made tests to use tmpfs for /var/log. Since then, I did not use much this so-called transient log: it cannot be seriously used on a server where you want your logs not tampered with in any way – and especially there in case of failure; it does not make laptop or workstation very silent since there is still a large amount of file access that is in ~/.

In the case of my laptop part alarm clock, many ~/.directories and ~/.files are regularly read or wrote. So I finally changed the initial transient log init script into /etc/init.d/shush-toram that reads /etc/default/shush-toram to determines which directories to put into tmpfs, for instance /var/log and /home/alarmclockuser. bviously, you don’t want to put on tmpfs in directory that would use all or more of your actual RAM. There is also a /etc/cron.daily/shush-toram job that’ll daily update the data on the hard disk (just calling the init script with reload or restart).

Once the scripts in place, you just have to do:

invoke-rc.d shush-toram start      # start it
update-rc.d shush-toram defaults   # set autostart

Yeah, that’s sysv init scripts. It’s probably not necessary that I discuss the merits of systemd. I tried it and was happy to boot faster than usual. Then I found that making init scripts with it was annoying, counterproductive for me. Then I found that my /var/log directory contained a subdirectory journal of more than 800 Mo – that can be fixed by editing some conffile obviously, but it’s not working clean out of the box. It just does not suits me. It could, and will surely, improve. Still, it’s being made mandatory here and there while it’s still counterproductive and unpolished. I’ll continue to make script for sysv -that can actually be started outside of sysv- since I’m likely to try to avoid systemd as much as possible.

The shush-toram files are included in my -utils general debian package.

Advertisements

Using RAM for transient data

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.