RAM disk: Difference between revisions
Line 5: | Line 5: | ||
===tmpfs and ramfs; shm and /run=== | ===tmpfs and ramfs; shm and /run=== | ||
If you want to ruse RAM as a disk, the immediate options in linux are: | |||
* '''ramfs''' is actually very thin wrapper exposing the RAM cacheing system as usable space. | * '''ramfs''' is actually very thin wrapper exposing the RAM cacheing system as usable space. | ||
Revision as of 14:19, 28 August 2023
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
If you want to ruse RAM as a disk, the immediate options in linux 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:
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 specific use - a bootstrapping thing: the purpose of linux's initramfs (previously initrd) is to mount the root filesystem.
initramfs
See also:
- https://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html
- https://wiki.debian.org/initramfs
- https://en.wikipedia.org/wiki/Initramfs
- http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html
rescueInitramfs
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.