文件系统

这篇文章是关于OpenWrt安装在内置闪存中的文件系统。 关于在其他设备上安装文件系统的一般外部支持，包括分区和挂载，请查看关于一般存储页面。

请同时阅读 → flash.layout 的内容. 此外, 请注意以下两种闪存的区别: NOR flash 和NAND flash. 以及阅读此篇 mtd文章。

用于合并两个文件系统，一个只读，另一个可写。在flash.layout 中解释了OpenWrt中如何使用它。

• OverlayFS
• Overlayfs 文档
• https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-2.6.38/209-overlayfs.patch?rev=26213
• Debating overlayfs on LWN.net
• Linux kernel 3.18 中作为主线
• Overlayfs 对inotify机制的支持还没有完成。像IN_CLOSE_WRITE这样的事件不能被通知给监听进程。

• tmpfs
• Kernel documentation on tmpfs
• /tmp位于一个tmpfs分区上，/var是它的符号链接；/dev位于它自己的一个小的tmpfs分区上。
• (+) 无损耗均衡
• (-) 非持久化存储 (重启后数据不再)

SquashFS 是一个只读压缩的文件系统。虽然gzip是可用的，但在OpenWrt它使用LZMA进行压缩。由于SquashFS是一个只读文件系统，它不需要对齐数据，允许它将文件打包得更紧，因此占用的空间比JFFS2少得多（比JFFS2文件系统节省20-30%的空间）!

• (+) 尽可能少地占用空间
• (+)由于不可写入，所以允许实施一个傻瓜式的FailSafe恢复。
• (-)只读
• (-) 浪费空间，因为每次修改其中包含的文件，实际上是将其副本复制到第二个（JFFS2）分区上
• Kernel documentation on SquashFS
• SquashFs Performance Comparisons

There is a generic problem when running SquashFS on NAND: The issue is that SquashFS has no bad block management at all and requires all blocks on order; but for proper NAND bad block management you also need to be able to skip bad blocks and occasionally relocate blocks (see squashfs and NAND flash). That's why raw SquashFS is a bad idea on NAND (it works if you use a FTL like UBIFS).

JFFS2 is a writable compressed filesystem with journaling and wear leveling using LZMA for the compression.

• (+) is writable, has journaling and wear leveling
• (+) is cool
• (-) is compressed, so a program (opkg in particular) cannot know in advance how much space a package will occupy
• (+) is compressed, so a program (which is preinstalled) takes much less space, so effectively you have more space

It was replaced with UBIFS.

• UBIFS is a file system for raw flash. It is used in OpenWrt NAND targets since :: around r40364
• Kernel documentation on UBIFS
• UBIFS File Encryption how does UBIFS understand what a “file” is? Isn't a file
• UBIFS File Encryption v1 on LWN.net
• UBIFS File Encryption v2 on LWN.net
• UBIFS Supports OverlayFS In Linux 4.9, Readying UBI For MLC Support

• ext2
• Ext2/3/4 is used on x86, x86-64 and for some arch with SD-card rootfs
• Kernel documentation on ext2
• (+) a program (opkg in particularly) knows how much space is left!
• (+) good ol' veteran FOSS file system
• (-) no journaling
• (-) no wear leveling
• (-) no transparent compression

OpenWrt does not use other filesystems as rootfs. It supports several filesystems attached to via various mechanisms like USB, SATA or network. For a list see storage.

• was used by older OpenWrt version and thus there are still references to this in the Wiki
• replaced by OverlayFS now.
• The mini_fo filesystem on LWN.net
• mini_fo: The mini fanout overlay file system official site

The flash.layout article documents how OpenWrt uses both SquashFS and JFFS2 filesystems combined into one filesystem by overlayfs. The kernel is also stored separately from these partitions in raw flash. When the kernel is built, it is also compressed with LZMA and gzip, as documented in imagebuilder.

System bootup is as follows: →process.boot

1. kernel boots from a known raw partition (without a FS), scans mtd partition rootfs for a valid superblock and mounts the SquashFS partition (containing /etc) then runs /etc/preinit. (More info at technical.details)
2. /etc/preinit runs /sbin/mount_root
3. mount_root mounts the JFFS2 partition (/overlay) and combines it with the SquashFS partition (/rom) to create a new virtual root filesystem (/)
4. bootup continues with /sbin/init

/overlay was previously named /jffs2

Both SquashFS and JFFS2 are compressed filesystems using LZMA for the compression. SquashFS is a read only filesystem while JFFS2 is a writable filesystem with journaling and wear leveling.
Our job when writing the firmware is to put as much common functionality on SquashFS while not wasting space with unwanted features. Additional features can always be installed onto JFFS2 by the user. The use of mini_fo/overlayfs means that the filesystem is presented as one large writable filesystem to the user with no visible boundary between SquashFS and JFFS2 -- files are simply copied to JFFS2 when they're written.
It's not all without side effects however.
The fact that we pack things so tightly in flash means that if the firmware ever changes, the size and location of the JFFS2 partition also changes, potentially wiping out a large chunk of JFFS2 data and corrupting the filesystem. To deal with this, we've implemented a policy that after each reflash the JFFS2 data is reformatted. The trick to doing that is a special value, 0xdeadc0de; when this value appears in a JFFS2 partition, everything from that point to the end of the partition is wiped. So, hidden at the end of the firmware images, is the value 0xdeadcode, positioned such that it becomes the start of the JFFS2 partition.
The fact that we use a combination of compressed and partially read only filesystems also has an interesting effect on package management:
In particular, you need to be careful what packages you update. While opkg is more than happy to install an updated package on JFFS2, it's unable to remove the original package from SquashFS; the end result is that you slowly start using more and more space until the JFFS2 partition is filled. The opkg util really has no idea how much space is available on the JFFS2 partition since it's compressed, and so it will blindly keep going until the opkg system crashes -- at that point you have so little space you probably can't even use opkg to remove anything.

On many embedded targets that use NOR flash for the root filesystem, OpenWrt implements a clever trick to get the most out of the limited flash memory capacity while retaining flexibility for the end-user:
Basically, during the image creation, all of the rootfs contents is packed up in a SquashFS filesystem -- a highly efficient filesystem with compression support. There's one important detail about it though: it is a read-only filesystem. To overcome this limitation OpenWrt uses the remaining portion of the NOR rootfs partition to store an additional read/write jffs2 filesystem which is “overlayed” on top of the rootfs (that is, allowing to read unchanged files from the SquashFS but storing all the modifications made to the jffs2 part).
This design has another important advantage for the end-user: even when the read/write partition is in total mess, he can always boot to the failsafe mode (which mounts only the squashfs part) and proceed from there.

The kernel boot process involves discovering of partitions within the NOR flash and it can be done by various target-dependent means:

• some bootloaders store a partition table at a known location
• some pass the partition layout via kernel command line
• some targets require specifying the kernel command line at the compile time (thus overriding the one provided by the bootloader).

Either way, if there is a partition named rootfs and MTD_ROOTFS_ROOT_DEV kernel config option is set to yes, this partition is automatically used for the root filesystem.

After that, if MTD_ROOTFS_SPLIT is enabled, the kernel adjusts the rootfs partition size to the minimum required by the particular SquashFS image and automatically adds rootfs_data to the list of the available mtd partitions setting its beginning to the first appropriate address after the SquashFS end and size to the remainder of the original rootfs partition. The resulting list is stored in RAM only, so no partition table of any kind gets actually modified.

For more details please refer to the actual patch at: https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-2.6.37/065-rootfs_split.patch

For overlaying a special mini_fo filesystem is used, the README is available from the sources at https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-2.6.37/209-mini_fo.patch

Note:: It is possible to contain the entire root filesystem on a JFFS2-Partition only, instead of a combination of both. The advantage is that changes to included files no longer leaves behind an old copy on the read only filesystem. So you could end up saving space. The disadvantage of this would be, that you have no failsafe any longer and also, JFFS2 takes significantly more space then SquashFS.

Yes, it's technically possible, but a bit of a mess to actually pull off. The firmware has to be loaded as a trx file, which means that you have to put the JFFS2 data inside of the trx. But, as I said above, the trx has a checksum, meaning that if you ever change that data, you invalidate the checksum. The solution is that you install with the JFFS2 data contained within the trx, and then change the trx-boundaries at runtime. The end result is a single JFFS2 partition for the root filesystem. Why someone would want to do it is beyond me; it takes more space, and while it would allow you to upgrade the contents of the filesystem you would still be unable to replace the kernel (outside of the filesystem), meaning that a seamless upgrade between releases is still not possible! Having SquashFS gives you a failsafe mechanism where you can always ignore the JFFS2 partition and boot directly off SquashFS, or restore files to their original SquashFS versions.

I used to have a trick where I could convert a SquashFS install to a JFFS2 install at runtime by copying all the data onto the SquashFS partition and changing the partition boundaries. I never really had much use for the util -- not to mention it required a rather large flash to store both SquashFS and JFFS2 copies of the root during transition -- so support for it was dropped.

Example pictures: on formatted partition / how data is stored (and addressed on ext3)

• how data is stored and addressed by ext2:
• how data is stored and addressed by ext3:
• how data is stored and addressed by SquashFS:
• how data is stored and addressed by JFFS2: