RAM disk notes
Contents
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)
The main differences:
- size:
- neither consumes RAM until you store something
- ramfs will grow as far as it can (so is up to apps using it to behave; will cause trashing when overused)
- 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
tmpfs is the safer choice.
To get a lot of use out of it, but avoid trashing, you could make a tmpfs disk and assign it no more than a good portion of typically-free RAM.
- Uses
Linuxes keep various transient runtime information in ram disks, largely because there's no point being slow, and/or wearing a disk for things you won't ever care to keep.
This includesThis 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:
zswap
Provides swap pages from RAM, rather than 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.
Technically, initramfs is actually a compressed cpio archive that the kernel unpacks into rootfs (itself a ramfs, or tmpfs, occsionally cramfs/squashfs), and at that point is the early root filesystem - basically early userspace)
Functionally, initramfs contains enough of the root filesystem to mount the real storage device you call the root filesystem that contains the OS there, so that the OS can start running.
In some cases it needs to do very little (e.g. mounting a typical disk by device path). When it doesn't need to do anything it can be empty.
In other cases it contains code/drivers to make it possible - consider booting from ZFS, LVM, encrypted disk, certain kinds of network boot.
...or adding some conveniences (such as the ability to specify the root disk by LABEL/UUID(verify)).
In a transient-VM sort of way you could even package your full app in there -- to clearly separate code from data.
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 cases, thin clients, system paritions on phones, liveCD/liveUSB, though in some cases only to save a little space.
