Analysis of root file system mount process

Original address: http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=27717694&id=3595123

First, memory disk INITRD (INITial Ram disk) technology
In the Linux operating system, there is a special feature-Initialize the memory disk INITRD (INITial Ram disk) technology, and the kernel supports compressed file system images. With these two features, we can start the Linux system from a small initialization memory disk and mount a portion of the system's memory as a root file system, and do not use the swap partition (which is perfectly possible if you are not running X windows), which means that the Linux system is completely embedded in memory. Instead of relying on any other hard drive. Now PC memory at least 128M, and the root file system used only 30MB, so not only will not make the performance of the machine down, but a great improvement.

Because the system does not work on the hard drive, so the system eliminates the problem caused by mechanical drive, because the system is running in memory, the root file system and operation completely in the CPU/RAM environment, systems performance in terms of speed and reliability is very good; it does not corrupt the file system due to illegal shutdown, Because every time we start, we extract the compressed file system to the memory disk as the root file system mount.

1 Hardware requirements
For such a system, the hardware does not require a special design, but only through the common PC components on the implementation. It is worth mentioning the size of the system's memory, it should be at least 64M. Because 30M as a ramdisk use, leaving more than 30 trillion as a system operation to ensure the normal operation of the system, our current computer memory is generally 128M, this condition can be met. The only special is a flash disk, which is equivalent to a hard disk with an IDE interface, size 20M, which is used primarily as a compression pack for starting Lilo and placing the root file system.

2 Use of RAMDisk
RAMDisk is a virtual disk technology based on memory, which adopts ext2 file system. RAMDisk is to allocate part of memory as a partition and use it as a hard disk. For programs that are constantly used by the system, placing them in RAMDisk will speed up the operation of the computer, such as large data network servers, diskless workstations, and so on. To be able to use RAMDisk, we need to select the RAMDisk support in the block device when compiling the kernel, which has two options, one setting RAMDisk size, the default is 4096k, and the other is INITRD support. It can be directly compiled into the kernel, or can be compiled into modules, when needed to load. We have to use it when we start it, so we have to compile it directly into the kernel.

If the support for RAMDisk has been compiled into the kernel, we can use it. First, create the directory RAM under the/MNT directory, run the Mkdir/mnt/ram, then create the file system for/DEV/RAM0, run Mke2fs/dev/ram, and finally Mount/dev/ram, run Mount/dev/ram/mnt/ram, You can manipulate it like a normal hard disk. It is noteworthy that when creating the file system, the screen output 1024 inodes, 4096 blocks, that is, RAMDisk size is 4m=4096 block, but after we mount, with the command Df–k/dev/ram view, show that the RAMDisk size is only 3963K, because the file system itself takes up some space.

3. The INITRD kernel can be used to load device drivers smoothly during the boot phase, however the INITRD has the following drawbacks:
(1) initrd size is fixed, such as the previous compression of the INITRD size is 4M (4k*1024), assuming that your root directory (miniroot/in the above example) total size is only 1M, it still takes up 4M of space. If you specify a size of 1M in the DD phase and then find that it is not enough, you must follow the steps above to start again.

(2) INITRD is a virtual block device, in the example above, you use FDISK to partition the virtual block device. In the kernel, read and write to a block device also passes through the buffer management module, that is, when the kernel reads the contents of the file in the INITRD, the buffer management thinks that the lower block device is slower and therefore enables the read and cache functionality. So the INITRD itself is in memory, while the block device buffer management also saves part of the content. In order to avoid the above shortcoming, so appeared Initramfs, its function and INITRD is similar,

The processing flow of the 4.linux2.4 kernel to INITRD is as follows:
(1). The boot loader loads the kernel and/DEV/INITRD content into memory,/DEV/INITRD is a device initialized by the boot loader, which stores initrd.

(2). During kernel initialization, the kernel/dev/initrd the contents of the device and copies it to the/DEV/RAM0 device.

(3). The kernel mounts the/DEV/RAM0 device as the original root file system in a readable and writable manner.

(4). If/DEV/RAM0 is designated as the real root file system, the kernel jumps to the last step to start normally.

(5). Execute the/LINUXRC file on INITRD, LINUXRC is usually a script file that loads the kernel to access the root file system must drive and load the root file system.

(6). /LINUXRC execution completed, the real root file system is mounted.

(7). If the real root file system exists in the/INITRD directory, then/DEV/RAM0 will move from/to/INITRD. Otherwise, if the/INITRD directory does not exist,/DEV/RAM0 will be uninstalled.

I say my own understanding: Here Ram0 is a virtual memory device that is automatically created to store ININRD. During kernel initialization, the kernel/dev/initrd the contents of the device and copies it to the/DEV/RAM0 device. and mount the/DEV/RAM0 device as the original root file system. If/DEV/RAM0 is specified like this, then/DEV/RAM0 is specified as the real root file system. If you do not specify a real root file system directly by using/DEV/HDA8, then you will use the default RAM0 storage initrd, and do the conversion in a certain way to mount the root file system to Hda8, both of which are ram0 to be used, and, in different ways, The first kind of direct ram0 as a root file system, the second run out of Ram0, but also to the root to hda8.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++

Second, the Mount root file system has a way
1.linux boot, after a series of initialization, you need to mount the root file system, for the final run Init process, such as preparation, mount root file system There are several ways:
(1) The filesystem already exists on a partition on the hard disk (or similar device), and the kernel is directly mount based on the command line arguments (ROOT=/DEV/XXX) that are started. Here is a problem, kernel how to find the corresponding device according to/dev/xxx when the root file system itself does not exist. The original kernel by directly resolving the device's name to obtain the device's master, from the device number, and then access to the corresponding device driver. So there is a long string of root_dev_names in the INIT/MAIN.C, which can be used to get the device number according to the device name.

(2) from the floppy drive, such as slow loading of the root file system, if the kernel support RAMDisk, in the load root file system, the kernel to determine the need to mount from the floppy disk (FDX), will automatically copy the file system image to RAMDisk, general corresponding equipment RAM0, Then mount the root file system on the RAM0. From the source view, if the kernel compiler does not support RAMDisk, and startup Parameters root=/dev/fd0, the system will be directly on the floppy disk mount, in addition to the slow speed, theoretically feasible (this I have not tried, do not know if it is kind. ）

(3) Use the INITRD to mount the root file system at startup. At first I was ramdisk and initrd these two things, in fact, RAMDisk only in RAM to implement the block device, INITRD can be said to be used in the start-up process of a mechanism. Just before loading Linux, bootloader can load a relatively small root file system image into a specified location in memory, and let this memory be called INITRD, Then, by passing parameters to the kernel initrd the starting address and size (or you can compile these parameters in the kernel), in the boot phase can temporarily use INITRD to mount the root file system. The original purpose of INITRD was to split the kernel into two phases: keep the least basic startup code in kernel, and then put support for a variety of hardware devices in a modular way in INITRD, This allows the required modules to be loaded from the root file system that INITRD mounts during the boot process. One advantage of this is that you can flexibly support different hardware by modifying the contents of the INITRD, while keeping the kernel unchanged. At the end of boot completion, the root file system can be reinstalled onto other devices, but it can no longer be reinstalled (many embedded systems are). The specific implementation process of INITRD is this: bootloader the root file system mapping to the memory designated location, the relevant parameters passed to the kernel, the kernel when the contents of the INITRD copy into the RAMDisk (RAM0), the INITRD occupied memory released, Mount the root file system on the RAM0. As you can see from this process, the kernel needs support for both RAMDisk and INITRD.

2. An implementation method of embedded system root file system. For systems that both kernel and root file systems are stored in flash, you can generally take advantage of the Linux-initiated INITRD mechanism. The specific process has been more clear, there is a point is in the boot parameters passed ROOT=/DEV/RAM0, so that the initrd to mount the root file system will not switch, because this time the actual device is RAM0. There is also the starting address parameter of the INITRD is a virtual address, which needs to correspond with the physical address used in bootloader.
namely: Root=/dev/ram0 initrd=0xc2000000,20m mem=128m

Three: the type of ROOTFS
Generally speaking, Rootfs is divided into two kinds: virtual Rootfs and Real rootfs. Now the trend of kernel is to put more functions into user space. To keep the kernel streamlined. Virtual Rootfs is also widely used by various Linux distributors. You can do a part of the initialization work in a virtual rootfs. Then switch to the real file system. During the development of virtual Rootfs. There are several versions of the following:
1.initramfs:initramfs is a technique introduced in kernel 2.5, which in fact means that a cpio package is attached to the kernel image, which contains a small file system that, when the kernel starts, unlocks the Cpio package. and the file system contained therein is released into the Rootfs, and part of the initialization code in the kernel is placed in the filesystem as a user-layer process. The obvious benefit is that the kernel's initialization code is streamlined and the kernel initialization process easier to customize. The rootfs of this way is contained in kernel image.
Rootfs in 2.cpio-initrd:cpio format
3.IMAGE-INITRD: The traditional format of the Rootfs

Four: The file system mount process
1. The first choice in the kernel boot process, initialization of the Rootfs file system, Rootfs and TMPFS are in-memory file system, its type is RAMFS. Then the ROOTF is mounted to the root directory.
[Start_kernel ()-> vfs_caches_init ()-> mnt_init ()]
void __init mnt_init (void) {
......
Init_rootfs ()//temporary ROOTFS file system registration
Init_mount_tree ()//temporary ROOTFS file system mount