2

In this introduction to initramfs, Robert Landley mentions the following as the motivation behind ramfs.

But ramdisks actually waste even more memory due to caching. Linux is designed to cache all files and directory entries read from or written to block devices, so Linux copies data to and from the ramdisk into the "page cache" (for file data), and the "dentry cache" (for directory entries). The downside of the ramdisk pretending to be a block device is it gets treated like a block device.

A few years ago, Linus Torvalds had a neat idea: what if Linux's cache could be mounted like a filesystem? Just keep the files in cache and never get rid of them until they're deleted or the system reboots? Linus wrote a tiny wrapper around the cache called "ramfs", and other kernel developers created an improved version called "tmpfs" (which can write the data to swap space, and limit the size of a given mount point so it fills up before consuming all available memory). Initramfs is an instance of tmpfs.

This leads me to believe that ramfs (and consequently initramfs) is a mechanism to expose the internal cache structure as a filesystem - using the initramfs driver.

But isn't the existence of the cache itself dependent on the existence of a block device to cache from? This would mean that even to create a purely RAM-based filesystem, we would need to create (or mock) a block device from where the ramfs would cache - which looks like the problem introduced by initrd in the first place. I'm sure I am missing something here but I am not sure what.

The cpio archive passed to the kernel can also resides on a block device (harddisk, typically), so in order to mount the initramfs contents wouldn't the kernel still need a filesystem driver?

1

For ramsfs/initrams, the device to cache the fs is "empty". If you look at the description in /Documentation/filesystems/ramfs-rootfs-initramfs.txt:

Normally all files are cached in memory by Linux. Pages of data read from backing store (usually the block device the filesystem is mounted on) are kept around in case it's needed again, but marked as clean (freeable) in case the Virtual Memory system needs the memory for something else. Similarly, data written to files is marked clean as soon as it has been written to backing store, but kept around for caching purposes until the VM reallocates the memory. A similar mechanism (the dentry cache) greatly speeds up access to directories.

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.

So a "mechanism to expose the internal cache structure as a filesystem" is not wrong, but not how I would describe it - it's a filesystem that uses the usual internal cache structure, but has no place to "back it up" (as ramdisk had), so it only lives in the cache, and the mechanisms to invalidate and write back pages are never used.

As for the cpio file, againlook at ramfs-rootfs-initramfs.txt:

The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image. (The directory linux-*/usr is devoted to generating this archive during the build.)

So the cpio is loaded using the same method the kernel is loaded, which can be from a block device, or over the network, or via pigeon carrier, or whatever. It doesn't matter. The bootloader takes care of that, the kernel doesn't need a filesystem driver.

0

The point of ramfs is that it gets rid of the block device. The contents of the file system is populated via the file system interface, and because there is no backing block device, the data stays in the cache. In the old way, the backing store acting as a block device into which a file system image was written. This was then mounted as a file system. The problem with this approach (RAM was cached in RAM) was solved, not by removing the cache, but instead removing the block device.

Yes, the cpio archive typically comes from a block device, but not necessarily. It could come from the network, a raw block device, etc. The cpio archive can optionally also be part of the kernel image. There must of course be a machanism for the boot loader to load the kernel and initramfs into RAM, but that is the boot loader's problem, not the kernel's. The point of the initramfs is that the final system can be very diverse, with a dozen or so different file systems to choose from, different lower level disk drive interfaces, etc. By using an initramfs, the kernel can be configured to be more generic, without the need to compile in a million drivers, which can instead be provided as modules. In fact, you don't need any file system driver in the kernel, they can all be loaded on demand as modules.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.