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.

Advertisements

Booting on a SATA drive with ASUS K8N4-E Deluxe mainboard

I noticed the  ASUS K8N4-E Deluxe mainboard, provided with Phoenix Technologies ACPI BIOS Revision 1008 simply won’t boot with a SATA drive while it does fine with a PATA (IDE) one. Not sure what specific part is at fault here.

 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3
 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
 05:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)

It boots with the following linux kernel options: irqpoll nolapic apm=power_off. I added them into /etc/defaut/grub before regenerating grub.cfg:

GRUB_CMDLINE_LINUX_DEFAULT="quiet irqpoll nolapic apm=power_off"

Note that, however, the shutdown does not halt physically the system. I’ll look into that later.