RAM disk: Difference between revisions
m (→zswap) |
mNo edit summary |
||
(11 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{#addbodyclass:tag_tech}} | |||
{{Computer hardware}} | |||
Taking some RAM and making it look like a disk, probably with a POSIX-style filesystem interface. | |||
This is used for temporary space, because it is much faster than doing the same on platter disk, | |||
and still a decent amount faster than SSD (and doesn't wear such an SSD) | |||
Line 5: | Line 13: | ||
===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. | ||
Line 11: | Line 20: | ||
:: {{comment|(so acts much more like the classical "allocates a fixed block of RAM" style ram disk)}} | :: {{comment|(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 | :: 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 | ||
Line 17: | Line 25: | ||
* size: | * size: | ||
:: neither consumes RAM until you store something | :: neither consumes RAM until you store something | ||
:: ramfs will grow as far as it can | :: ramfs will grow as far as it can | ||
:: tmpfs will report an error when it hits its limit (will act like a full disk) | :: tmpfs will report an error when it hits its limit (will act like a full disk) | ||
Line 25: | Line 33: | ||
* swap: | * swap: | ||
:: ramfs is not eligible for swap | :: ramfs is not eligible for swap | ||
:: tmpfs is eligible for swap | :: tmpfs is eligible for swap | ||
While ramfs is the sometimes-lower-latency option | |||
int that there can be no swapping via possibly-slow IO, | |||
it also means it is up to ''every'' app that uses it to to behave; "will not swap" combined with " can always grow" means you can very efficiently run yourself out of free RAM, cause [[trashing]] and system instability. | |||
Line 88: | Line 102: | ||
This is a bootstrapping thing. | This is a specific use - a bootstrapping thing: the purpose of linux's initramfs (previously initrd) is to mount the root filesystem. | ||
====initramfs==== | |||
<!-- | |||
The basic initramfs is the root filesystem image used for booting the kernel, and is effectively a RAM disk | |||
initramfs is loaded by the kernel | |||
The sole purpose of initramfs (or its predecessor, initrd) is to mount the root filesystem. | |||
As a file, it contains | |||
: microcode | |||
: a basic filesystem | |||
The initramfs contains a minimal set of directories that you would find on a normal root filesystem. | |||
It is bundled into a single cpio archive and compressed with (one of several compression algorithms). | |||
the kernel{{verify}} unpacks the initramfs image into rootfs (itself a ramfs, or tmpfs, occsionally cramfs/squashfs), and at that point ''is'' the early root filesystem | |||
Functionally, initramfs contains enough to find and mount the real ''storage'' device you call the root filesystem, so that it can start the real OS running. | |||
In some cases it needs to do very little (e.g. mounting a single local disk by device path, containing little more than a basic filesystem driver), and can be nearly empty. | |||
--> | |||
<!-- | |||
Why? | |||
In part, this early stage of boot isn't really related to a running system. | |||
Separating the codebase from the kernel codebase is partially just simpler. | |||
Also, it makes it easier to customize the contents of this early part of boot. | |||
And do so with user tools and user-space tools - no need to patch the kernel. | |||
Also, most of that code is fine being userspace, | |||
so keeping it out of the kernel is safer and more secure. | |||
This requirement will flush a lot of in-kernel "magic" currently used by the initialization code; the result will be cleaner, safer code. | |||
It includes: | |||
--> | |||
<!-- | |||
Depending on use, it may contain a bunch more things | |||
* further filesystem drivers | |||
: e.g. like ZFS if you choose to boot off it | |||
* encrypted disk stuff | |||
* RAID/mdadm stuff | |||
* LVM style stuff | |||
* 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. | |||
--> | |||
<!-- | |||
In debian/ubuntu, | |||
sudo update-initramfs -u | |||
--> | |||
<!-- | |||
'''When initramfs fails''' | |||
Ha. Fun. | |||
It depends on how, but '''usually'', it just means a necessary driver didn't get included. | |||
https://askubuntu.com/questions/1268943/after-upgrade-to-20-04-luks-doesnt-open-my-disk-on-boot-cryptroot-crypttab-is | |||
--> | |||
See also: | See also: | ||
* https://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html | |||
* https://wiki.debian.org/initramfs | |||
* https://en.wikipedia.org/wiki/Initramfs | * https://en.wikipedia.org/wiki/Initramfs | ||
* http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html | * http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html | ||
====rescueInitramfs==== | |||
===cramfs, squashfs=== | ===cramfs, squashfs=== |
Latest revision as of 16:46, 22 April 2024
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
|
Taking some RAM and making it look like a disk, probably with a POSIX-style filesystem interface.
This is used for temporary space, because it is much faster than doing the same on platter disk, and still a decent amount faster than SSD (and doesn't wear such an SSD)
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
- 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
- tmpfs is eligible for swap
While ramfs is the sometimes-lower-latency option int that there can be no swapping via possibly-slow IO, it also means it is up to every app that uses it to to behave; "will not swap" combined with " can always grow" means you can very efficiently run yourself out of free RAM, cause trashing and system instability.
- 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.