is this exactly what romfs in Linux kernel does?

Question

I have to create a file system with customized loadable modules with romfs. However, I have a few confusions (I'm still new to the kernel stuffs):

• After reading romfs document: romfs , as far as I know, romfs is a filesystem similar to ext2, ext3, ext4.... , which is used to create init ramdisk required at boot time by the kernel. However, it is said that romfs is incorporated into the kernel since version 2.1.21: romfs homepage . On the homepage, we can only download the genromfs utility, which is used to create romfs image file. So, I want to be clear here: the module romfs included in the kernel is for reading romfs filesystem, and genromfs is used to create one, isn't it (I tried genromfs , but I want to be confirmed)?

• initrd is created by mkinitrd -allow-missing -f initrd.img kernel-version at a source directory (the filesystem to be loaded) and unpackaged by: gzip -dc initrd.img | cpio -idv gzip -dc initrd.img | cpio -idv , while using romfs, I have to create its image by using mkinitrd and unpackage it using: genromfs -fdv romfs.img . Is this the same as initrd at kernel boot time? initrd involves compressing, while romfs is not, is this ok?

• If so, the romfs module has to be built into the kernel for reading at early kernel boot phase, is that right? In my system, we have a diskless machine, and currently, initrd is used as a boot phase filesystem as well as final root filesystem. However, since romfs is meant for read only, is using romfs denied users the ability to write into filesystem (so, we can't do thing like echo "something" > /tmp/something.txt )?

Answer 1

For (1), yes, the module romfs is the file system that supports a simple read-only file system that is very simple in implementation. The program genroms allows you to create an instance of a romfs file system that can be mounted and accessed under a kernel that has the romfs module loaded.

The genromfs tool generates a file system image that can be placed on a block device, or onto a file on a pre-existing file system.

For (2), you can use a romfs file system as an initial ram disk - as long as there is compiled-in kernel support for accessing a romfs file system. The difference comes at initrd load time. For a standard initrd image, it gets decompressed into the ramdisk that is used to initiate boot, with a romfs image, it is not uncompressed, it is simply used as-is.

The primary reason for using a romfs image as a file system is that it could be placed onto a block of read-only memory, and accessed directly in that manner without needing to use physical memory for the expanded ramdisk image.

For (3), yes, you must compile the file system into the system as a built-in component, rather than a loadable module - ie you choose ' Y ' for the rom file system option in the kernel file system configuration.

I would not recommend using a romfs file system as a root file system - there are insufficient POSIX attributes (ownership, permissions) to allow it to run as a proper file system for general day-to-day use (I don't know for certain; I just would find using a file system like this very strange )

An initrd is decompressed into memory at run-time, so any writing to the file system is not persisted after a reboot of the system. If the file system on that expanded ramdisk has the appropriate permissions, then the kernel should prevent changes being made by ordinary users to specific content on the disk. You would not allow the user to log onto the system as root, and rely on the permissions of the file system from preventing modifications to the files.

The fact that it is read-only and unmodifiable means that if you wanted to have a /tmp file, then you would need to have created the directory as part of the genromfs call, and then you would have to mount tmpfs onto that mount point in order to perform a write into that directory.

If you're looking for a way of having a root file system that is read-only, then you should consider mounting a read-only share from a remote file system; that way there is no actual way for the user to make modifications to the file system - all write efforts would be rejected by the server. By using a feature like FS-Cache/CacheFS , the performance would be quite good.

Answer 2

The romfs filesystem has basically fallen out of use today, as it is very limited. You would only use it if you had a large read-only medium and no interest in compression.

It used to be that the initrd was a romfs image that was mounted from the RAM block where it was loaded, and after unmount, the RAM block was freed; this has been replaced by a tmpfs instance (read/write RAM based filesystem) that is initialized with data from a cpio format archive (similar to a ZIP file).

There is a point in the boot process where the kernel unloads all code that will never be needed again ("Freeing init memory"), this happens right before process 1 is started. With the romfs approach, the initrd is mounted from the initrd image at this point, so the code required for accessing the romfs image as well as the initrd code must remain loaded here, which means that you end up with some dead kernel code after the system is booted.

The current initrd approach uses the same ramdisk code that is also used later for the /tmp filesystem (if your system is configured this way), and the entire initialization of that filesystem is run before the point where the memory is freed, so no dead code remains loaded after the initrd is booted.

Neither romfs nor cpio format initrds can be written to; the new code path copies the data to a writeable filesystem first, which allows your initrd scripts to write data; however this is never written back into the image.