Tmpfs and ramfs

How it works

Linux uses pages and dentries to cache files and directories
(respectively) temporarily in memory to speed things up. When the
virtual memory subsystem
needs this memory for something else, the caches & dentries are flushed to a
backing store. In the interest of brevity, this store is a block
device, like your hard disk.

When you use either tmpfs or ramfs, there is no backing store.
Trippy.

Differences between tmpfs or ramfs

Only two major things, really.

  1. tmpfs can use swap while ramfs cannot
  2. tmpfs cannot grow dynamically while ramfs can

Using tmpfs or ramfs

tmpfs

A simple tmpfs mount. This will default to half the size of system
memory:

mount -t tmpfs tmpfs /tmp

Mount tmpfs, but limit it to 200MB, owned by user joe and group
fisherman:

mount -t tmpfs tmpfs /mnt/volatile -o size=200M,uid=12,gid=107

The man page also says that you can tweak with block and inode counts
for your mount (nr_blocks and nr_inodes).

ramfs

A simpler gentleman; no mount options whatsoever:

mount -t ramfs ramfs /mnt/volatile

Can you free memory after using it?

With ramfs, there is no backing store.  Files written into ramfs allocate
 dentries and page cache as usual, but there’s nowhere to write them to.
 This means the pages are never marked clean, so they can’t be freed by the
 VM when it’s looking to recycle memory.

I’m guessing that this is the case with tmpfs as well. You’ll probably
need to reboot the system. However, and to test this, I put two
184,320,000-byte files into /dev/shm and played around with them. Here
are some numbers:

# Before   
MemTotal:      1026888 kB  
MemFree:        376068 kB  
SwapTotal:     2064376 kB  
SwapFree:      1891908 kB  
  
# After copying 2x180MB into 502MB tmpfs mount  
MemTotal:      1026888 kB  
MemFree:         33672 kB  
SwapTotal:     2064376 kB  
SwapFree:      1891908 kB  
  
# After removing one 180MB file  
MemTotal:      1026888 kB  
MemFree:        213364 kB  
SwapTotal:     2064376 kB  
SwapFree:      1891908 kB

Observe that swap hasn’t changed. I also couldn’t get perfect arithmetic
accounting for the free memory, but it seemed close enough. Bottom-line
is that I don’t know what to think of this (yet).

/dev/shm: A ready tmpfs solution

Look at the output of df -ah on most Linux boxes. You’ll see the
highlighted:

Filesystem            Size  Used Avail Use% Mounted on  
/dev/mapper/VolGroup00-LogVol00  
                       73G  2.8G   66G   5% /  
proc                     0     0     0   -  /proc  
sysfs                    0     0     0   -  /sys  
devpts                   0     0     0   -  /dev/pts  
/dev/sda1              99M   25M   70M  26% /boot  
tmpfs                 502M     0  502M   0% /dev/shm
none                     0     0     0   -  /proc/sys/fs/binfmt_misc  
sunrpc                   0     0     0   -  /var/lib/nfs/rpc_pipefs  
/root/tmpfs           191M  176M   15M  93% /root/tmpfs

/dev/shm (shm = shared memory) is automatically mounted to occupy half
your physical memory at most by default. If you’re not happy with
this, go ahead and change it:

mount -o remount,size=1G /dev/shm

Other Points

  • Don‚Äôt ever think that merely mounting tmpfs, ramfs, or
    /dev/shm will actually reserve (or ‚Äėcordon off‚Äô) memory.
  • In low-memory situations, swap is used as a backing store. This
    means that you’re not going to see a huge performance boost with
    tmpfs. And I think you’d appreciate a live (albeit sluggish)
    system rather than one that’s crashed due to a reckless use of
    ramfs. Swings and roundabouts.