ramdisk, ramfs, tmpfs, rootfs, initrd and initramfs

ramfs, rootfs and initramfs

ramdisk

The older "ram disk" mechanism created a synthetic block device out of an area of RAM and used it as backing store for a filesystem. This block device was of fixed size, so the filesystem mounted on it was of fixed size. Using a ram disk also required unnecessarily copying memory from the fake block device into the page cache (and copying changes back out), as well as creating and destroying dentries. Plus it needed a filesystem driver (such as ext2) to format and interpret this data.

Compared to ramfs, this wastes memory (and memory bus bandwidth), creates unnecessary work for the CPU, and pollutes the CPU caches.
The RAM disk is simply unnecessary; ramfs is internally much simpler.

Another reason ramdisks are semi-obsolete is that the introduction of loopback devices offered a more flexible and convenient way to create synthetic block devices, now from files instead of from chunks of memory.

ramfs

Ramfs is a very simple filesystem that exports Linux's disk caching mechanisms (the page cache and dentry cache) as a dynamically resizable RAM-based filesystem.
A disk cache is a software mechanism that allows the system to keep in RAM some data that is normally stored on a disk, so that further accesses to that data can be satisfied quickly without accessing the disk.
Normally all files are cached in memory by Linux:

• Pages of data read from backing store ( the block device the filesystem is mounted on ) are kept around in case it's needed again, but marked as clean (freeable)
• data written to files is marked clean as soon as it has been written to backing store, but kept around for caching purposes

The dentry cache stores dentry objects representing filesystem pathnames, the page cache is a disk cache working on whole pages of data.
The page cache can be used to retrieve single blocks of data (for instance, superblocks and inodes); this feature is crucial to speed up the VFS and the disk-based filesystems.

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.

The amount of code required to implement ramfs is tiny, because all the work is done by the existing Linux caching infrastructure. Basically, you're mounting the disk cache as a filesystem.

tmpfs

tmpfs (temporary file system) is a virtual filesystem created to store files in dynamic (volatile) memory. tmpfs is typically created on RAM( or swap partitions ).
Mounting directories as tmpfs can be:

• an effective way of speeding up accesses to their files
• ensure that their contents are automatically cleared upon reboot

ramfs has been replaced by tmpfs as the old ramfs did not handle well when the system run out of memory.
tmpfs allows the filesystem to grow dynamically when it needs more space until it hits the pre-set maximum value it has been allocated; after that it will use swap space if it is available.

Generate and mount tmpfs in one step:

#mount -t tmpfs tmpfs /MOUNTPOINT

Users can specify the mount option size to control the maximum size of the filesystem.
To check the mounted information:

$ findmnt /run
TARGET SOURCE FSTYPE OPTIONS
/run   tmpfs  tmpfs  rw,nosuid,noexec,relatime,size=395408k,mode=755

rootfs

rootfs is a special instance of ramfs(or tmpfs, if that's enabled).

Mounting the root filesystem is a two-stage procedure,

1. The kernel mounts the special rootfs filesystem, which simply provides an empty directory that serves as initial mount point.
2. The kernel mounts the real root filesystem over the empty directory.

Why does the kernel bother to mount the rootfs filesystem before the real one?
In fact, in some cases, the kernel mounts and unmounts several root filesystems, one after the other.
Most systems just mount another filesystem over rootfs and ignore it. The amount of space an empty instance of ramfs takes up is tiny.
If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by default. To force ramfs, add "rootfstype=ramfs" to the kernel command line.

initrd

initrd (initial ramdisk) is a scheme for loading a temporary root file system into memory, which may be used as part of the Linux startup process.
initrd and initramfs refer to two different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.
The bootloader will load the kernel and initial root file system image into memory and then start the kernel, passing in the memory address of the image. At the end of its boot sequence, the kernel tries to determine the format of the image from its first few blocks of data, which can lead either to the initrd or initramfs scheme.
Depending on which algorithms were compiled statically into it, the kernel can unpack initrd/initramfs images compressed with gzip, bzip2, LZMA, XZ, LZO, and LZ4.

In the initrd scheme, the image may be a file system image (optionally compressed), which is made available in a special block device (/dev/ram) that is then mounted as the initial root file system.
The driver for that file system must be compiled statically into the kernel. Many distributions originally used compressed ext2 file system images, while the others (including Debian 3.1) used cramfs in order to boot on memory-limited systems, since the cramfs image can be mounted in-place without requiring extra space for decompression.
Once the initial root file system is up, the kernel executes /linuxrc as its first process; when it exits, the kernel assumes that the real root file system has been mounted and executes /sbin/init to begin the normal user-space boot process.

The /dev/initrd is a read-only block device assigned major number 1 and minor number 250. Typically /dev/initrd is owned by root.disk with mode 0400 (read access by root only). It can be created with the following commands:

mknod -m 400 /dev/initrd b 1 250
chown root:disk /dev/initrd  
  

To use /dev/initrd, both CONFIG_BLK_DEV_RAM=y("RAM disk" support) and CONFIG_BLK_DEV_INITRD=y("Initial RAM disk" support) must be compiled directly into the Linux kernel.
The special file /dev/initrd is a read-only block device. This device is a RAM disk that is initialized ( loaded) by the boot loader before the kernel is started. The kernel then can use /dev/initrd's contents for a two-phase system boot-up:

1. the first boot-up phase
• The boot loader loads the kernel program and /dev/initrd's contents into memory.
You have to specify the RAM disk image file in bootloader's configuration file.( initrd=path )
• The kernel starts up and mounts an initial root file-system from the contents of /dev/initrd.
• The kernel then read-write mounts the device /dev/ram0 as the initial root file system.
• If the real root file system is also indicated as the initial root file-system (e.g., root=/dev/ram0 ) then the kernel starts for the usual boot sequence ( invocation of /sbin/init)). The 2nd phase is skipped.
2. the second phase
• If the executable file /linuxrc is present in the initial root file-system, /linuxrc is executed with UID 0.
• If /linuxrc is not executed or when /linuxrc terminates, the real root file system is mounted.
• If the normal root file system has a directory /initrd, the device /dev/ram0 is moved from / to /initrd. Otherwise if the directory /initrd does not exist, the device /dev/ram0 is unmounted.
• The kernel starts for the usual boot sequence ( invocation of /sbin/init)).

The initrd method had a few drawbacks:

• a block device
It is a full-fledged block device, requiring the overhead of an entire file system; it has a fixed size. Choosing an initrd that is too small and all needed scripts cannot fit. Make it too big and memory will be wasted.
• memory cosumption
Because it is a real, static device it consumes cache memory in the Linux kernel and is prone to the memory and file management methods in use (such as paging), this makes initrd greater in memory consumption.

To resolve these issues the initramfs was created.

initramfs

An initramfs is an initial ram file system based on tmpfs (a size-flexible, in-memory lightweight file system).
Just like the initrd, it contains the tools and scripts needed to mount the file systems before the init binary on the real root file system is called.
In the initramfs scheme (available since the Linux kernel 2.6.13), the image may be a cpio archive (optionally compressed).
cpio is an old (but proven) file archiver solution (and its resulting archive files are called cpio files). The choice of cpio here was because it was easier to implement (code-wise) and supported device files which tar did not support at the time.
cpio copies files between archives and directories.
Recent kernels have support for populating a ramdisk from a compressed cpio archive.
The creation of a ramdisk image doesn’t need to involve special block devices or loopbacks:

• create a directory on disk with the desired initrd content
• cd to that directory , and run (as an example):

find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/initrd.img

Dump the contents of an existing image file:

mkdir tmp; cd tmp;
gzip -cd ../initrd.img | cpio -imd --quiet

The initramfs image is unpacked by the kernel into a special instance of a tmpfs that becomes the initial root file system.
This scheme has the advantage of not requiring an intermediate file system or block drivers to be compiled into the kernel.

Once the kernel detected the initramfs, the kernel will create a tmpfs file system, extract the contents of the archive on it, and then launch the init script located in the root of the tmpfs file system.
This script then mounts the real root file system (after making sure it can mount it, for instance by loading additional modules, preparing an encryption abstraction layer, etc.) as well as vital other file systems (such as /usr and /var ).
Once the root file system and the other vital file systems are mounted, the init script from the initramfs will switch the root towards the real root file system and finally call the /sbin/init binary on that system to continue the boot process.

Some systems use the dracut package to create an initramfs image.In the initramfs scheme, the kernel executes /init as its first process that is not expected to exit.[5] For some applications, initramfs can use the casper utility to create a writable environment using unionfs to overlay a persistence layer over a read-only root filesystem image. For example, overlay data can be stored on a USB flash drive, while a compressed SquashFS read-only image stored on a live CD acts as a root filesystem

Squash Filesystem

squashfs is inherently read-only.

Squash FS Howto

An Overview of the SquashFS filesystem