Introduction to Embedded Linux File System

Linux supports a variety of file systems, including ext2, ext3, vfat, ntfs, iso9660, jffs, romfs, and nfs. The class file system provides a unified operation interface and application programming interface. When Linux starts, the first thing that must be mounted is the root file system; if the system cannot mount the root file system from the specified device, the system will fail to start with an error. Additional filesystems can then be mounted automatically or manually. Therefore, different file systems can exist in one system at the same time.
Different file system types have different characteristics, so they have different application scenarios according to the hardware characteristics and system requirements of the storage device. In embedded Linux applications, the main storage devices are RAM (DRAM, SDRAM) and ROM (FLASH memory is often used). Commonly used file system types based on storage devices include: jffs2, yaffs, cramfs, romfs, ramdisk, ramfs/ tmpfs etc.

RAM-based file system
initramfs
initramfs is compiled at the same time as the kernel and generates an image file with the kernel, which can be compressed or uncompressed, but currently only supports the cpio package format. It is a very simple method of making and making a root file system, and you can also boot the real file system by executing the program in this file system, so that the work of loading the root file system is not the work of the kernel, but the work of initramfs . Since initramfs uses the cpio package format, it is easy to compile and link a single file, directory, and node to the system, which is very convenient to use in such a very simple system, and there is no need to mount another file system.
However, because the cpio package is actually a description language package for files, directories, and nodes, in order to describe a file, directory, and node, a lot of extra description text overhead is added. Especially for directories and nodes, the extra description text itself is very small. A lot, which makes the cpio package much larger than the corresponding image file.
ramdisk
Ramdisk is a memory-based virtual file system (not an actual file system), which uses a portion of the fixed-size (this size is configured when compiling the kernel's make menuconfig) memory as a partition on the hard disk. A ramdisk is a mechanism to mount an actual filesystem into memory and can act as a root filesystem, usually we would format it with an ext2 or ext3 filesystem. Since ramdisk operates in memory, we can add, modify, delete, etc. to the files in it, but when the power is turned off, there is nothing left. Due to this feature, we can put some frequently accessed files (such as the read-only root file system) in memory through Ramdisk, which can significantly improve the performance of the system.
In the startup phase of Linux, the kernel and ramdisk are loaded into the specified location of the memory by the bootloader at startup (), and initrd provides a mechanism to load the kernel image and the root file system into the memory. initrd is the boot loader initialized RAM disk. As the name implies, it is the ramdisk used when the system is initialized and booted. Its function is to improve the module mechanism of the kernel and make the initialization process of the kernel more flexible.　
ramfs/tmpfs
Ramfs is a memory-based file system developed by Linus Torvalds. It works at the virtual file system (VFS) layer, cannot be formatted, and can be created multiple times. The maximum memory size that can be used can be specified at the time of creation. (In fact, VFS can be regarded as an in-memory file system in essence, which unifies the representation of files in the kernel and buffers the disk file system.) The Ramfs/tmpfs file system puts all files in RAM, Therefore, the read/write operation occurs in RAM, and ramfs/tmpfs can be used to store some temporary or frequently modified data, such as the /tmp and /var directories, which not only avoids the read and write loss of the Flash memory, but also improves the Data read and write speed. The main difference between Ramfs/tmpfs and traditional Ramdisk is that it cannot be formatted, and the size of the file system can vary with the size of the contained files. But none of them can be used as a root file system like ramdisk, but can only be used as a pseudo file system like procfs and devfs.
nfs
NFS Network File System (Network File System) is a technology developed and developed by Sun to share files between different machines and different operating systems through the network. In the development and debugging stage of the embedded Linux system, this technology can be used to establish a root file system based on NFS on the host and mount it to the embedded device, so that the content of the root file system can be easily modified.
Pseudo file system
The above discussion is based on the storage device file system (memory-based file system), they can be used as the root file system of Linux (except tmpfs and ramfs). In fact, Linux also supports logical or pseudo file systems, such as procfs (proc file system) for obtaining system information, and devfs (device file system) and sysfs for maintaining device files.
FLASH-based file system
Flash (flash memory), as the main storage medium of embedded systems, has its own characteristics. The write operation of Flash can only change the 1 of the corresponding position to 0, but cannot change 0 to 1 (erasing the Flash is to restore the content of the corresponding memory block to 1). Therefore, in general, write content to the Flash. , the corresponding storage area needs to be erased first, and this erasing is performed in units of blocks.
Flash memory mainly has two technologies: NOR and NAND (see appendix for a simple comparison). The number of erasing and writing of Flash memory is limited, and NAND flash memory also has special hardware interfaces and read and write timings. Therefore, a file system that meets the application requirements must be designed according to the hardware characteristics of Flash; traditional file systems such as ext2, etc., used as a file system for Flash will have many drawbacks.
Under embedded Linux, MTD (Memory Technology Device) provides a unified abstract interface between the underlying hardware (flash memory) and the upper layer (file system), that is, the file system of Flash is based on the MTD driver layer ( See the file system structure diagram under Linux below). The main advantage of using the MTD driver is that it is specially designed for all kinds of non-volatile memory (mainly flash memory), so it has better support, management and sector-based erasing, reading and /Write interface.
By the way, a Flash chip can be divided into multiple partitions, and each partition can use different file systems; two Flash chips can also be combined into one partition and use one file system. That is, the file system is for the memory partition, not the memory chip.
jffs2
The JFFS file system was first developed by the Swedish Axis Communications Company based on the Linux2.0 kernel for embedded systems. JFFS2 (Journalling Flash FileSystem v2, journaling flash file system version 2) is a flash file system developed by RedHat based on JFFS. It was originally an embedded file system developed for RedHat's embedded product eCos, so JFFS2 can also be used in Linux, uCLinux. It is mainly used in NOR-type flash memory and is based on the MTD driver layer. It is characterized by: readable and writable, data compression, hash table-based log file system, and provides crash/power-down safety protection, providing "write balance" "Support etc. The main disadvantage is that when the file system is full or close to full, jffs2 runs much slower because of garbage collection.
Jffs2 is not suitable for NAND flash memory mainly because the capacity of NAND flash memory is generally large, which leads to a rapid increase in the memory space occupied by jffs2 for maintaining log nodes. In addition, the jffs2 file system needs to scan the entire FLASH content when it is mounted. In order to find all the log nodes and establish the file structure, it will take a lot of time for large-capacity NAND flash memory.
Currently jffs3 is under development. For the detailed documentation on the use of jffs2 series file systems, please refer to mtd-jffs-HOWTO.txt in the MTD patch package.
yaffs2
yaffs/yaffs2 (Yet Another Flash File System) is a journaling file system designed for embedded systems using NAND flash memory. Compared with jffs2, it has reduced some features (such as no support for data compression), so it is faster, has a short mount time, and has a smaller memory footprint. In addition, it is also a cross-platform file system, in addition to Linux and eCos, it also supports WinCE, pSOS and ThreadX, etc.
yaffs/yaffs2 comes with a NAND chip driver, and provides an API for directly accessing the file system for embedded systems. Users can directly operate the file system without using MTD and VFS in Linux. Of course, yaffs also works with the MTD driver. The main difference between yaffs and yaffs2 is that the former only supports small page (512 Bytes) NAND flash memory, while the latter can support large page (2KB) NAND flash memory. At the same time, yaffs2 has greatly improved in terms of memory space occupation, garbage collection speed, and read/write speed.
The ubifs
Unsorted Block Image File System (UBIFS) is used on SSD storage devices and competes with LogFS as one of the successor file systems of JFFS2. The real development started in 2007, and in October 2008, it was first added to the stable version in Linux kernel version 2.6.27. UBIFS was first designed by IBM and Nokia engineers Thomas Gleixner and Artem Bityutskiy in 2006, specifically to solve the bottleneck encountered by MTD (Memory Technology Device) equipment. Due to the skyrocketing capacity of Nand Flash, YAFFS and others can no longer control the space of Nand Flash. UBIFS handles actions with the MTD device through the subsystem UBI. Like JFFS2, UBIFS is built on top of MTD device, so it is not compatible with general block device.
JFFS2 runs on MTD devices, while UBIFS can only work on UBI volumes. It can also be said that UBIFS involves three subsystems:
1. MTD subsystem, which provides an access interface to the flash chip, MTD subsystem provides the concept of MTD device, such as /dev/mtdx, MTD can be considered as raw flash
2. UBI subsystem, which provides wear-leveling and volume management functions for flash devices; UBI works on top of MTD devices and provides UBI volume; UBI is a high-level representation of MTD devices, which shields the upper layer from some things that MTD has to deal with Problems, such as wearing and bad block management
3. UBIFS file system, working on top of UBI
Here are some features of UBIFS:
Scalability: UBIFS has good scalability for flash size; that is, mount time, memory consumption and I/O speed does not depend on flash size (not completely accurate for memory consumption, but the dependency is very low); UBIFS can be well adapted to GB flashes; of course UBI itself has scalability issues, in any case UBI /UBIFS is more scalable than JFFS2, and if UBI becomes a bottleneck, you can also upgrade UBI without changing UBIFS  
 to mount quickly: unlike JFFS2, UBIFS does not need to scan the entire file system during the mount phase, and UBIFS mounts media time It is only in milliseconds, and the time does not depend on the size of the flash; however, the initialization time of UBI depends on the size of the flash, so this time must be taken into account.
Write-back support: Write-back or delayed write is more accurate, same as JFFS2 Compared to write-through (immediately written to memory), file system throughput can be significantly improved.  
 Abnormal unmount fitness: UBIFS is a journaling file system that can tolerate sudden power failure and unclean restart; UBIFS recovers unclean unmount by replaying the log. In this case, replay will take some time, so the mount time will increase slightly, but the replay process The entire flash media is not scanned, so the mount time for UBIFS is about a fraction of a second.
Fast I/O - Even if we disable write-back (you can use the -o sync mount option when unmounting), UBIFS still performs close to JFFS2; remember, JFFS2's synchronous I/O is amazing because JFFS2 doesn't need to The indexing data structure is maintained on the flash, so there is no burden brought by it; and UBIFS just has index data. The reason UBIFS is fast enough is because of the way UBIFS commits the log: instead of moving data from one place to another, just add the address of the data to the index of the file system, and then select a different eraseblock as the new log block, in addition There are also tricks such as multi-headed logging.  
on-the_flight compression - data stored on the flash medium is compressed; it is also possible to flexibly turn compression on and off for individual files; for example, compression may need to be turned on for a specific file, or compression may be supported by default , but compression is turned off for multimedia files.
Recoverability - UBIFS can recover from index corruption; each piece of information in UBIFS is described by a header, so the filesystem can be reconstructed by scanning the flash media, which is very similar to JFFS2; imagine if you Erase the FAT table of the FAT file system, it is a fatal error for FAT FS, but if you erase the index of UBIFS, you can rebuild the file system, of course, this requires a specific user space program to do this recovery  
complete Properties - UBIFS ensures data integrity by writing checksums to flash media, UBIFS does not ignore corrupt file data or meta-data; by default, UBIFS only checks the CRC of meta-data, but you can force it with the mount option Check
cramfs for data CRC
Cramfs (Compressed ROM File System) is a read-only compressed file system developed by the founder of Linux, Linus Torvalds. It is also based on the MTD driver. In the cramfs file system, each page (4KB) is compressed separately and can be accessed randomly. The compression ratio is as high as 2:1, which saves a lot of Flash storage space for embedded systems and enables the system to store through lower capacity FLASH. the same files, thereby reducing system costs.
The Cramfs file system is stored in a compressed manner and decompressed at runtime, so it does not support applications running in XIP mode. All applications are required to be copied to RAM to run, but this does not mean that the RAM space required by Ramfs is larger than that of Ramfs. One point, because Cramfs uses paging compression to store files, when reading files, it will not consume too much memory space at once, and only allocate memory for the part that is actually read at present, and the part that has not been read does not. Allocate memory space. When the file we read is not in memory, the Cramfs file system automatically calculates the location where the compressed data is stored, and then decompresses it into RAM in real time.
In addition, it is fast and efficient, and its read-only feature helps protect the file system from damage and improves the reliability of the system. Cramfs images are usually placed in Flash, but can also be placed in other filesystems, which can be mounted on other filesystems using a loopback device.
Due to the above characteristics, Cramfs is widely used in embedded systems. But its read-only property is also its major flaw, making it impossible for users to expand its content.
romfs
The traditional Romfs file system is a simple, compact, read-only file system that does not support dynamic erasing and saving, and stores data in sequence, so it supports applications in XIP (eXecute In Place, on-chip operation) mode Run, save RAM space while the system is running. The uClinux system usually uses the Romfs file system.
other file systems
fat/fat32 can also be used for extended memory in actual embedded systems (eg SD cards for PDAs, Smartphones, digital cameras, etc.), mainly for better compatibility with the most popular Windows desktop operating systems. ext2 can also be used as a file system for embedded Linux, but using it for FLASH flash memory has many disadvantages.