嵌入式Linux文件系统选型指南：从JFFS2到F2FS的实战解析

1. 项目概述：为什么嵌入式Linux文件系统是个“技术活”？

干了十几年嵌入式开发，从早期的uClinux到如今复杂的多核异构系统，我经手过的板子少说也有上百款。每次项目启动，硬件选型、内核裁剪、驱动调试这些“硬骨头”啃完后，总有一个环节容易被新手忽视，却又在后期频频“爆雷”——那就是文件系统的选型与构建。很多人觉得，文件系统嘛，不就是把根文件系统（Rootfs）烧进去，能挂载、能读写就行。但真到了产品量产，面临高温低温、频繁断电、存储介质寿命、OTA升级等现实场景时，一个不合适的文件系统选型，轻则导致数据丢失、系统卡顿，重则直接让产品“变砖”，售后电话被打爆。

嵌入式Linux世界里的文件系统，远不止我们桌面PC上常见的Ext4或NTFS那么简单。它是一个根据存储介质特性、数据安全需求、性能要求和产品生命周期综合权衡后的技术选型集合。比如，你的产品用的是NOR Flash还是NAND Flash？是eMMC还是SD卡？需不需要应对突然断电？对启动速度有多敏感？这些问题的答案，直接决定了你该用JFFS2、YAFFS2、UBIFS，还是F2FS，或者是它们的某种组合。这次，我就结合自己踩过的坑和积累的经验，把这潭水给大家捋清楚，讲明白每种文件系统的“脾气秉性”和适用场景，让你在项目初期就能做出最合适的选择，避免后期推倒重来的巨大成本。

2. 核心需求解析：嵌入式场景对文件系统的特殊要求

在开始罗列具体文件系统之前，我们必须先搞清楚，在资源受限、环境严苛的嵌入式设备上，我们对文件系统究竟有哪些不同于桌面或服务器的核心诉求。理解了这些，你才能明白为什么会有这么多“稀奇古怪”的文件系统存在。

2.1 对存储介质的高度适配

嵌入式设备使用的存储介质五花八门，每种介质都有其独特的物理特性，文件系统必须为此“量身定制”。

• NOR Flash：支持XIP（就地执行），读取快，但写入和擦除速度慢，且擦除单位大（通常64KB-128KB）。它像一本可以直接翻到某一页阅读的书，但想修改某一页，必须把整章撕掉重写。针对它的文件系统（如JFFS2）必须能高效处理这种“擦除-写入”的不对称性。
• NAND Flash：容量大、成本低，但存在坏块、需要ECC校验、读写单位不对称（页读写、块擦除）。它像一本有很多页，但偶尔有几页印刷模糊（坏块）的书，阅读和修改都需要遵循特定的规则。YAFFS2和UBIFS就是为它而生的。
• eMMC/UFS：可以看作是集成了闪存控制器的“智能”NAND，内部已经做了FTL（闪存转换层）来模拟块设备。对于上层系统，它看起来更像一个硬盘。因此，Ext4、F2FS这类为块设备设计的文件系统有了用武之地。
• SD/TF卡：同样属于块设备，但质量参差不齐，寿命和稳定性是最大挑战。文件系统需要具备较强的损坏恢复能力。

注意：千万不要把为NAND设计的YAFFS2用在NOR上，或者把为块设备设计的Ext4直接用在原始NAND上，这会导致性能极差甚至损坏存储介质。适配性是第一原则。

2.2 对数据可靠性的极致追求

嵌入式设备，尤其是工业、车载、医疗设备，面临频繁的意外断电。想象一下，设备正在写入关键配置或日志时突然掉电，文件系统不能因此崩溃或丢失大量数据。

• 掉电安全：文件系统的设计必须保证在任何一次写操作中，如果发生掉电，重启后要么是旧数据，要么是新数据，绝不能是损坏的或中间状态的数据。这通常通过日志（Journaling）或写时复制（Copy-on-Write）机制来实现。
• 磨损均衡：Flash介质每个存储单元的擦写次数是有限的（通常1万到10万次）。如果频繁更新同一个区域（比如某个日志文件），该区域会率先损坏。优秀的闪存文件系统必须将写操作均匀分布到整个存储空间，延长整体寿命。
• 坏块管理：NAND Flash出厂时就有坏块，使用中还会产生新的坏块。文件系统必须能自动检测、标记并跳过这些坏块，对上层应用透明。

2.3 对系统资源的精打细算

嵌入式设备的CPU、内存都相对紧张。文件系统不能太“臃肿”。

• 内存占用：文件系统驱动运行时需要占用RAM，包括缓存、索引结构等。在只有几十MB内存的系统中，一个占用十几MB内存的文件系统是不可接受的。
• CPU开销：在完成读写操作时，加解密、压缩、ECC校验等操作会消耗CPU资源。需要在功能、安全和性能之间取得平衡。
• 存储空间开销：文件系统自身的元数据（如inode表、位图）会占用一部分存储空间，称为“开销”。对于小容量存储，这个比例需要尽可能低。

2.4 对特定功能的场景化需求

• 压缩：对于只读的根文件系统，压缩可以极大节省存储空间（SquashFS）。
• 快照：系统升级或配置回滚时非常有用。
• 透明加密：保护用户数据安全。
• 性能优化：针对小文件读写、顺序读写或随机读写进行优化。

3. 闪存专用文件系统深度剖析

这类文件系统直接面向Flash的物理特性设计，通常不需要下层的FTL，是“最原生”的嵌入式选择。

3.1 JFFS2：NOR Flash的经典守卫者

JFFS2（Journalling Flash File System version 2）是为NOR Flash设计的日志结构文件系统。它的核心思想是：不在原地覆盖旧数据，而是将数据和元数据的更新以“节点”的形式追加写入到Flash的空白区域。垃圾回收（GC）线程会在后台将有效数据整理到新块，并擦除无效数据所在的旧块。

工作流程与特点：

1. 追加写：所有更新都写到Flash的末尾空闲位置。
2. 日志结构：整个Flash可以看作一个环形的日志，写指针不断向前推进。
3. 挂载扫描：系统启动时，JFFS2会扫描整个Flash，在内存中重建文件目录结构。Flash越大，挂载时间越长，这是它的主要缺点。
4. 磨损均衡：通过总是在最新空白处写入，自然实现了磨损均衡。

实操心得：

• 适用场景：小容量（建议<128MB）NOR Flash。在早期基于NOR的嵌入式路由器、工控设备中非常常见。
• 避坑指南：
  • 挂载时间：这是最头疼的问题。一个256MB的Flash，挂载可能需要十几秒。优化方法是使用summary特性，它在正常关闭时会在Flash末尾写入一个摘要信息，下次挂载时只需读取摘要，极大加快速度。但意外掉电后，summary可能无效，仍需全盘扫描。
  • 内存占用：文件数越多，内存中维护的节点信息就越多。对于文件数量巨大的系统（如成千上万个文件），内存消耗会很可观。
  • 写放大：由于日志结构和垃圾回收，实际写入Flash的数据量可能远大于上层请求的数据量，影响Flash寿命和写性能。

配置示例（Linux内核）：

# 使能JFFS2 CONFIG_JFFS2_FS=y # 选择压缩模式（推荐zlib） CONFIG_JFFS2_ZLIB=y # 启用summary支持以减少挂载时间（强烈建议） CONFIG_JFFS2_SUMMARY=y

3.2 YAFFS2：直接面向NAND的先行者

YAFFS（Yet Another Flash File System）是第一个专门为NAND Flash设计的文件系统。YAFFS2是其第二代版本。它的设计非常直观：将文件直接映射到NAND的页（Page）上，每个文件（或文件的一部分）对应一个或多个数据块，并有一个对应的对象头（Object Header）来存放元数据。

核心机制：

1. 页级管理：以NAND的页为单位分配数据。
2. 对象头：每个文件/目录都有一个对象头，存放名称、权限、长度等信息。对象头和数据页是分开存储的。
3. 垃圾回收：当块内有效数据很少时，GC会将其中的有效数据搬走，然后擦除整个块。

实操心得：

• 适用场景：大容量NAND Flash，特别是在Android早期版本中广泛应用。
• 优势：设计简洁，代码可读性好，挂载速度快（只需要扫描对象头所在的页）。
• 劣势与现状：
  • 单线程GC：垃圾回收是单线程的，在写入压力大时可能造成系统卡顿。
  • 社区停滞：YAFFS2的官方维护已基本停滞，内核主线很早就移除了对YAFFS2的支持。这意味着在新版内核中使用它需要打补丁，有维护风险。
  • 功能较少：相比UBIFS，缺乏如压缩等高级功能。
• 个人建议：对于新项目，除非有极强的历史包袱或特定需求，否则不建议选择YAFFS2。UBIFS是更现代、更强大的替代品。

3.3 UBIFS：现代NAND闪存的推荐选择

UBIFS（Unsorted Block Image File System）是YAFFS2的“继任者”，它构建在UBI（Unsorted Block Images）卷管理层之上。这种分层设计是它的精髓所在。

UBI+UBIFS架构解析：

1. MTD层：最底层，是Linux内核提供的“内存技术设备”抽象，直接操作Flash的读写擦。
2. UBI层：这是关键的一层。它管理多个物理擦除块（PEB），并将其抽象为逻辑擦除块（LEB）提供给上层。UBI负责：
   • 磨损均衡：在逻辑块和物理块之间动态映射，确保所有物理块磨损均匀。
   • 坏块管理：透明处理坏块。
   • 逻辑卷管理：可以将一个物理Flash分区划分为多个UBI卷，每个卷可以格式化为不同的文件系统（如UBIFS、SquashFS）。
3. UBIFS层：运行在UBI卷之上的真正文件系统。它也是日志结构，但设计更复杂和高效。

UBIFS的核心优势：

• 出色的性能：尤其是多线程读写和垃圾回收，比YAFFS2流畅。
• 强大的功能：支持透明压缩（LZO, zlib, Zstd），可以节省空间并减少写入量。支持快照。
• 更快的挂载：挂载时只需读取很少的索引信息，速度远快于JFFS2的全盘扫描。
• 社区活跃：是Linux内核主线的一部分，持续维护和优化。

实操配置与踩坑记录：

1. 内核配置：必须同时启用MTD、UBI和UBIFS。

   CONFIG_MTD=y CONFIG_MTD_UBI=y CONFIG_UBIFS_FS=y CONFIG_UBIFS_FS_LZO=y # 启用LZO压缩 CONFIG_UBIFS_FS_ZLIB=y # 启用zlib压缩

2. Flash分区与UBI附着：这是最容易出错的一步。假设你的NAND Flash有一个MTD分区叫mtd5。

   # 1. 擦除MTD分区并附着到UBI，创建UBI设备（如ubi1） ubiformat /dev/mtd5 -y ubiattach -m 5 -d 1 # 2. 在ubi1上创建UBI卷（如卷名为rootfs，大小为所有可用空间） ubimkvol /dev/ubi1 -N rootfs -m # 此时会生成设备节点 /dev/ubi1_0 # 3. 格式化卷为UBIFS mkfs.ubifs -r /path/to/rootfs -m 2048 -e 126976 -c 2048 -o ubifs.img # -m: 最小I/O单元大小（页大小），如2KiB # -e: 逻辑擦除块大小（物理块大小-开销），如124KiB（128KiB-4KiB） # -c: 最大逻辑块数 # 4. 将镜像写入卷（使用ubinize打包，因为需要包含UBI卷表信息） ubinize -o ubi.img -m 2048 -p 128KiB -s 2048 ubinize.cfg # ubinize.cfg 配置文件指定了卷名、大小、类型等 # 5. 最后通过nandwrite将ubi.img烧写到mtd5

3. 参数计算是灵魂：-m,-e,-c这几个参数必须与你的Flash芯片规格严格匹配。-e（LEB大小）的计算公式是：物理擦除块大小 - (2 * 页大小)。例如，页大小2KB，块大小128KB，则LEB = 128KB - 2*2KB = 124KB。参数不对会导致文件系统无法挂载或数据损坏。
4. 压缩选择：LZO压缩速度快，但压缩率低；zlib压缩率高，但CPU消耗大。根据你的CPU性能和存储空间权衡。实测在ARM Cortex-A7上，LZO对系统性能的影响几乎可忽略。

4. 通用（块设备）文件系统在嵌入式的应用

随着eMMC、SD卡、SSD等带有FTL的块设备在嵌入式领域普及，传统的磁盘文件系统也有了用武之地。它们通常更成熟、功能更全、工具链更完善。

4.1 Ext4：稳定与性能的平衡之选

Ext4是Ext3的进化版，是目前Linux桌面和服务器最主流的文件系统，其稳定性和性能经过了海量验证。

在嵌入式中的适用性分析：

• 优点：
  • 极度稳定：代码经过千锤百炼，数据可靠性高。
  • 功能完整：支持扩展属性、日志、大文件（>2TB）、纳秒时间戳等。
  • 工具链完善：e2fsprogs工具包（mkfs.ext4, fsck.ext4, resize2fs等）功能强大。
  • 性能均衡：在大多数读写场景下表现良好。
• 缺点与注意事项：
  • 非掉电安全：虽然Ext4有日志，但其默认的ordered日志模式只能保证文件系统元数据的一致性，不能保证文件数据在掉电时不丢失。data=journal模式可以保证，但性能损失巨大。对于频繁意外断电的工业场景，Ext4需要谨慎评估。
  • 针对Flash优化不足：它不知道底层是Flash，无法做磨损均衡。这部分依赖eMMC/SD卡内部的FTL。如果FTL算法差，设备寿命会受影响。
  • 空间开销：固定大小的inode表会占用一部分空间，对于极小容量的存储不友好。

嵌入式优化配置：

# 格式化时常用参数 mkfs.ext4 -O ^has_journal /dev/mmcblk0p1 # 禁用日志，提升速度，但牺牲安全性 mkfs.ext4 -O ^metadata_csum /dev/mmcblk0p1 # 禁用元数据校验和，节省CPU，轻微风险 mkfs.ext4 -E stride=512,stripe_width=1024 /dev/mmcblk0p1 # 针对RAID或Flash优化分配策略 # /etc/fstab 挂载参数 defaults,noatime,nodelalloc,data=writeback # - noatime: 不更新访问时间，减少写操作 # - nodelalloc: 禁用延迟分配，避免掉电时数据丢失风险（但可能影响碎片化） # - data=writeback: 最高性能的日志模式，但安全性最低

4.2 F2FS：为Flash而生的现代文件系统

F2FS（Flash-Friendly File System）是三星推出的，真正意义上为基于Flash的存储设备（尤其是SSD和eMMC）设计的文件系统。它充分考虑了Flash的擦写特性。

核心设计理念：

1. 基于日志的写策略：但日志是循环的、多区域的，减少了写放大。
2. 多头部日志：将热数据（频繁更新）和冷数据（很少更新）分开存放，便于垃圾回收。
3. 自适应分区：动态调整数据、节点、段信息的分布，优化空间利用和性能。
4. 线程化垃圾回收：更积极、更平滑，避免系统突然卡顿。

在嵌入式eMMC上的实战表现：我在一个基于eMMC的智能家居网关上做过对比测试（Cortex-A53， 8GB eMMC）：

• 顺序写入：Ext4和F2FS相差不大。
• 随机小文件写入：F2FS明显快于Ext4，尤其是在长时间使用后，Ext4会因为碎片化性能下降，而F2FS影响较小。
• 磁盘满时的性能：当eMMC使用超过90%时，Ext4的性能会急剧下降，而F2FS下降相对平缓。
• CPU和内存开销：F2FS的元数据更复杂，内存占用略高于Ext4。GC线程也会消耗一定CPU。

适用建议：

• 强烈推荐用于用户数据分区，特别是需要频繁存储、删除小文件的应用（如浏览器缓存、应用数据、日志）。
• 谨慎评估用于只读或几乎只读的系统分区，因为F2FS的优势在于写优化，对于纯读场景，其收益不大，反而增加了复杂性。
• 务必启用fstrim：定期（如每周一次）或在下文删除大量文件后，手动执行fstrim，通知F2FS哪些块已空闲，这对维持长期性能至关重要。

配置示例：

# 格式化 mkfs.f2fs -f -l MYDATA /dev/mmcblk0p2 # /etc/fstab 挂载参数 defaults,noatime,background_gc=on,active_logs=6 # - background_gc=on: 开启后台垃圾回收 # - active_logs=6: 设置活动日志段数，影响性能

5. 只读与内存文件系统的特殊角色

除了可读写的持久化文件系统，嵌入式系统里还有两位不可或缺的“配角”。

5.1 SquashFS：超高压缩率的只读文件系统

SquashFS将整个文件系统目录树压缩成一个只读的块。它本身不是一个块设备驱动，需要配合一个回环设备（loop device）或MTD的只读分区（如UBI只读卷）来使用。

为什么根文件系统常用SquashFS？

1. 极高的压缩比：使用gzip, xz, lzo等算法，通常可以将根文件系统压缩到原来的30%-50%。对于存储空间寸土寸金的嵌入式设备，这节省的空间是巨大的。
2. 只读，天然防篡改：系统核心部分不需要写入，只读可以防止被意外修改或病毒破坏，提升系统安全性。
3. 节省内存：文件数据是直接从存储介质解压到内存页缓存中，不需要在内存中保存完整的解压后镜像。

典型应用：OverlayFS 根文件系统这是最经典的组合。系统启动时：

1. 将一个SquashFS镜像（包含系统所有基础文件）挂载为下层（lowerdir），只读。
2. 将一个可读写的文件系统（如UBIFS, Ext4）挂载为上层（upperdir），用于存放运行时产生的所有修改（如配置、日志、临时文件）。
3. 通过OverlayFS将两者合并成一个统一的视图（merged dir），作为根文件系统。 这样，既享受了SquashFS的压缩节省空间和只读安全，又获得了可写分区保存数据的能力。系统升级时，只需要替换SquashFS镜像即可。

制作与使用：

# 1. 制作SquashFS镜像 mksquashfs rootfs_dir rootfs.squashfs -comp xz -b 256K # -comp 指定压缩算法，xz压缩率高但慢，lzo快但压缩率低 # -b 指定块大小，影响随机访问性能和压缩率 # 2. 在UBI卷上使用（假设ubi1_0是只读卷） ubiupdatevol /dev/ubi1_0 rootfs.squashfs # 3. 内核挂载OverlayFS (启动脚本中) mount -t squashfs /dev/ubi1_0 /mnt/squash mount -t ubifs /dev/ubi2_0 /mnt/overlay/work -o rw # 可写工作目录 mount -t overlay overlay -o lowerdir=/mnt/squash,upperdir=/mnt/overlay/upper,workdir=/mnt/overlay/work /new_root

5.2 tmpfs & ramfs：内存中的疾速空间

两者都是将内存的一部分当作文件系统来使用，速度极快。

• tmpfs：大小可限制，支持交换分区（swap）。当tmpfs中的文件不再被使用时，内存页可以被系统回收。它是临时文件存储的首选，如/tmp、/var/run目录。

  # /etc/fstab 示例 tmpfs /tmp tmpfs defaults,size=100M,nr_inodes=100k,mode=1777 0 0 # size: 限制最大大小，防止耗尽内存 # nr_inodes: 限制最大文件数量 # mode=1777: 设置粘滞位，用户只能删除自己的文件

• ramfs：大小不可限制，会一直增长直到耗尽所有内存。不使用交换分区。因为缺乏限制，除非有特殊需求，否则一般使用tmpfs代替ramfs。

使用场景：任何不需要持久化的临时数据、缓存、socket文件等，都应该放在tmpfs中，这能极大减少对Flash的写入，延长其寿命，并提升访问速度。

6. 选型决策与综合实战指南

面对这么多选择，到底该怎么选？我总结了一个简单的决策流程和一张对比表。

第一步：确定你的存储介质

• 原始NOR Flash->JFFS2(小容量) /UBIFS(需通过UBI)
• 原始NAND Flash->UBIFS(强烈推荐) / YAFFS2 (遗产维护)
• eMMC、SD卡、SSD->Ext4(稳定优先) /F2FS(写入频繁，性能优先)

第二步：确定分区用途

• 只读系统分区->SquashFS(通过OverlayFS与可写层结合)
• 可写系统分区/数据分区-> 根据第一步选择Ext4/F2FS/UBIFS
• 临时数据分区->tmpfs

第三步：考虑额外需求

• 极致压缩-> SquashFS (只读)
• 掉电安全要求极高-> UBIFS, JFFS2 (闪存原生) > Ext4 (data=journal)
• 海量小文件存储-> F2FS, UBIFS
• 工具链和社区支持-> Ext4, UBIFS

主流嵌入式文件系统对比表

一个典型的现代嵌入式Linux存储布局示例：假设我们有一个4GB的eMMC和一颗小容量SPI NOR Flash。

1. SPI NOR (16MB)：
   • mtd0: 2MB- U-Boot
   • mtd1: 1MB- U-Boot环境变量
   • mtd2: 1MB- Linux内核 (可能压缩)
   • mtd3: 12MB-UBI分区，内含：
     • ubi0: u-boot配置备份(小UBIFS卷)
     • ubi1: 恢复用SquashFS根文件系统(只读)
2. eMMC (4GB)：
   • mmcblk0p1: 128MB-Ext4，用于主系统根文件系统的可写Overlay层和内核。
   • mmcblk0p2: 3.5GB-F2FS，用于用户数据、应用安装、下载。
   • mmcblk0p3: 剩余空间-Ext4，用于日志、诊断数据等。
3. 内存：
   • tmpfs- 挂载到/tmp,/var/run,/var/lock。

系统从NOR Flash启动，内核加载后，将eMMC上的Ext4分区和NOR Flash上UBI卷里的SquashFS通过OverlayFS合并为根文件系统。这样既保证了核心启动的可靠性（NOR Flash），又获得了大容量存储和优秀的数据分区性能（eMMC+F2FS）。

7. 常见问题与排查技巧实录

在实际开发和维护中，文件系统相关的问题五花八门。这里记录几个最让我印象深刻的“坑”及其排查思路。

问题一：UBIFS挂载失败，报错“Invalid argument”

• 现象：使用mount -t ubifs ubi1:rootfs /mnt命令时失败。
• 排查：
  1. 首先确认UBI设备是否成功附着：cat /proc/mtd和ls /dev/ubi*。
  2. 检查卷是否存在：ubinfo /dev/ubi1。
  3. 最关键的一步：核对mkfs.ubifs和ubinize时使用的-m(最小IO单元)、-e(逻辑擦除块大小)、-c(最大逻辑块数)参数，是否与当前Flash的物理参数以及内核中UBI模块的配置一致。99%的“Invalid argument”都是这几个参数不对。使用ubinfo -d 1可以查看已创建卷的实际参数。
  4. 检查内核配置是否包含了对应Flash型号的MTD驱动以及UBI/UBIFS支持。

问题二：系统运行一段时间后，根文件系统突然只读

• 现象：设备运行几周或几个月后，无法创建或删除文件，dmesg显示文件系统错误并remount为只读。
• 排查：
  1. 对于Ext4/F2FS：首先检查存储介质健康度。使用smartctl（对于eMMC/SD）或mmc相关调试命令，查看坏块计数、磨损等级。这很可能是硬件寿命将至或FTL故障。
  2. 对于UBIFS/JFFS2：检查是否存储空间已满。Flash文件系统在空间不足时，垃圾回收可能无法进行，导致写入失败而触发只读。使用df和ubinfo查看可用空间。
  3. 检查内核日志dmesg | tail -50，寻找具体的I/O错误信息。可能是驱动不稳定、电源波动导致写操作异常。
  4. 一个隐蔽原因：OverlayFS的上层可写分区满了。即使下层SquashFS有空间，上层满了也会导致合并层无法写入。检查你的OverlayFS上层目录所在分区。

问题三：F2FS分区性能随时间明显下降

• 现象：新设备很快，但用户使用一段时间后，感觉保存文件、安装应用变慢。
• 排查与解决：
  1. 首要操作：检查分区剩余空间。F2FS在空间不足时性能下降比Ext4更明显。确保用户可用空间不低于总容量的10%。
  2. 执行手动TRIM：fstrim -v /data。如果长时间未TRIM，SSD/eMMC内部需要处理大量无效数据，性能会下降。可以将fstrim加入每周的定时任务。
  3. 检查挂载参数。尝试启用background_gc=on和增加active_logs数量（如设为6或8），这能提升并发垃圾回收能力。
  4. 如果问题依旧，使用fsck.f2fs检查并修复文件系统（注意：先备份数据！）。

问题四：JFFS2挂载时间过长，影响启动速度

• 现象：基于NOR Flash的设备，启动时在“VFS: Mounted root (jffs2 filesystem)”这里停留几十秒。
• 优化：
  1. 启用Summary：这是最有效的方法。确保内核配置CONFIG_JFFS2_SUMMARY=y，并且在系统正常关机时，JFFS2会写入summary信息。但需接受意外掉电后首次启动仍会慢的事实。
  2. 减少文件数量：精简根文件系统，删除不必要的文件。JFFS2挂载时间与文件数量正相关。
  3. 考虑迁移：如果容量允许且项目处于早期，可以考虑将根文件系统改为SquashFS+UBI只读卷的形式，彻底解决挂载慢的问题。

文件系统的选择和调优，是嵌入式系统设计中一个深水区，它没有银弹，只有最适合当前产品需求和硬件约束的权衡之选。我的经验是，在项目预研阶段，就用真实的硬件和近似真实的数据负载，对候选的文件系统进行长时间的读写、掉电、老化测试。数据比任何理论都更有说服力。希望这篇长文能帮你建立起嵌入式文件系统的知识框架，少走一些我当年走过的弯路。