RAM disk

The lower-level parts of computers General: Computer power consumption · Computer noises Memory: Some understanding of memory hardware · CPU cache · Flash memory · Virtual memory · Memory mapped IO and files · RAM disk · Memory limits on 32-bit and 64-bit machines Related: Network wiring notes - Power over Ethernet · 19" rack sizes Unsorted: GPU, GPGPU, OpenCL, CUDA notes · Computer booting

Linux

tmpfs and ramfs; shm and /run

The immediate options for RAM disks are:

• ramfs is actually very thin wrapper exposing the RAM cacheing system as usable space.

• tmpfs, based on ramfs, adds a size limit and swappability

(so acts much more like the classical "allocates a fixed block of RAM" style ram disk)

and is a bunch safer due to the size limit - though still, pay attention to giving it no more than a good portion of typically-free RAM

The main differences:

• size:

neither consumes RAM until you store something

ramfs will grow as far as it can (so it's up to apps that are using it to behave; overuse will cause trashing)

tmpfs will report an error when it hits its limit (will act like a full disk)

• df:

ramfs adds to the 'cached' figure in free/top

tmpfs shows as a drive in e.g. df

• swap:

ramfs is not eligible for swap (this is sometimes can be preferable for speed guarantees)

tmpfs is eligible for swap

Uses

Linuxes keep various transient runtime information in ram disks, largely because there's no point contending for for disk for something you won't ever care to keep.

This includes /var/lock (locks), /var/run (runtime state), /dev/shm (modest data passing), and others that can be distro-specific.

This is usually backed by tmpfs.

Some distros decided to migrate (for now symlink) this stuff to /run so a single mount covers them all - see e.g. [1]

zram

In the linux kernel since 3.2(verify)

zram (previously compcache) provides block devices that are backed by memory and transparently compressed (lzo, lz4, more?).

Uses up to a predefined uncompressed maximum size.

(TODO: figure out whether it's eligible for swap)

This can make sense for

• scratch space

• certain caches, e.g. ZFS L2ARC on zram can make sense

• backing compressed swap, effectively increasing the amount of available RAM when things are swapped out, without using disk to do it

...but these days you probably want to use zswap for that

See also:

• https://www.kernel.org/doc/Documentation/blockdev/zram.txt
• https://wiki.gentoo.org/wiki/Zram

zswap

Provides swap pages from RAM, rather than from a block device.

Effectively an layer between RAM and disk swap: if the zswap pool is full, or RAM is exhausted, zswap moves pages to disk swap in an LRU style.

Difference between zswap and zram-which-you-happen-to-use-to-back-swapspace

• zram-for-swap is a few more commands

• zram-used-for-swap is separate from existing swap

so zswap is cleverer when there is disk swap

and zram often works better when there won't be other swap configured

See also:

• https://wiki.archlinux.org/index.php/Zswap#Compression_algorithm
• https://en.wikipedia.org/wiki/Zswap

initrd, initramfs

This is a bootstrapping thing.

The purpose of initramfs (previously initrd) is to mount the root filesystem.

See also initramfs

See also:

• https://en.wikipedia.org/wiki/Initramfs
• http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html

cramfs, squashfs

(squashfs has replaced cramfs)

Read-only filesystem with low overhead, most useful for embedded devices, thin clients, system partitions on phones, liveCD/liveUSB.

In some cases the read-only nature is part of the design and means an embedded device can't easily brick itself, in other cases (e.g. liveUSB) it's mainly to save a little space.