3、文件系统选型概览：常见嵌入式文件系统（JFFS2、UBIFS、ext4、F2FS、SquashFS、initramfs）的优缺点与适用场景

在嵌入式Linux系统中，文件系统直接决定了存储介质的寿命、数据可靠性、启动速度以及运行时性能。Buildroot作为嵌入式构建工具，提供了多种文件系统格式的生成支持，但选错格式往往会导致产品在量产后面临掉电损坏、磨损过快或启动缓慢等严重问题。本章将系统对比六种主流嵌入式文件系统的内部机制、适用边界与选型判断路径，帮助工程师在项目初期做出合理的存储架构决策。

3.1 核心原理：从存储介质特性理解文件系统设计差异

嵌入式文件系统的设计本质上是围绕存储介质的物理特性展开的。NAND Flash 以页（Page）为读写单位、以块（Block）为擦除单位，且存在有限的擦写寿命（通常 SLC 为 10 万次，MLC 为 1 万次左右）。NOR Flash 支持随机读取和字节写入，但擦除块较大且容量较小。eMMC 和 SSD 内部由主控芯片管理 Flash 转换层（FTL），对外呈现为块设备，屏蔽了擦除和磨损均衡的细节。

基于这些差异，文件系统分为两大阵营：一类是Flash 专用文件系统（JFFS2、UBIFS、F2FS），它们直接管理裸 Flash 设备，自行处理磨损均衡、坏块管理和掉电恢复；另一类是块设备文件系统（ext4、F2FS 在 eMMC 上），它们依赖设备自身的 FTL 层，更关注元数据性能、日志和扩展性。SquashFS 和 initramfs 则属于特殊用途：前者是只读压缩文件系统，后者是内存文件系统。

理解这一层差异是选型的基础。如果硬件平台使用 NAND Flash 且没有 FTL 层，那么 ext4 根本无法直接工作，必须选择 UBIFS 或 JFFS2。反之，如果使用 eMMC，则 UBIFS 反而无法使用，因为 eMMC 对操作系统呈现为块设备而非 MTD 设备。

3.2 六种文件系统深度对比

3.2.1 JFFS2：老牌 Flash 文件系统

JFFS2（Journalling Flash File System version 2）是最早广泛使用的 Flash 文件系统之一。它采用日志结构（Log-structured）设计，所有数据变更以节点形式追加写入，垃圾回收机制在后台合并有效节点并擦除无用块。JFFS2 的优点是实现简单、无需 FTL、支持压缩，在 NOR Flash 上表现稳定。但其缺点也很明显：挂载时需要扫描整片 Flash 建立文件索引，导致挂载时间随容量线性增长；内存占用随文件数量增加而膨胀；垃圾回收在高水位时可能引起写入停顿。

在 Buildroot 中启用 JFFS2 需要配置 MTD 支持和对应的内核驱动。对于 64MB 以下的 NOR Flash，JFFS2 仍然是一个可靠选择，但超过 128MB 后建议转向 UBIFS。

3.2.2 UBIFS：NAND Flash 的现代选择

UBIFS 由 UBI（Unsorted Block Images）层和日志文件系统组成。UBI 层负责将物理擦除块映射为逻辑擦除块，实现磨损均衡、坏块管理和掉电恢复。UBIFS 在此基础上提供高效的 B+ 树索引，挂载速度远快于 JFFS2，且支持写缓冲和异步 I/O，吞吐量显著提升。UBIFS 还支持在线压缩（zlib/lzo/zstd），适合存储日志、配置等频繁写入的数据。

使用 UBIFS 需要在内核中启用 UBI 和 UBIFS 支持，并在 Buildroot 中通过 BR2_TARGET_ROOTFS_UBIFS 生成镜像。实际部署时通常配合 UBI 卷管理，将根文件系统放在一个 UBI 卷中，数据分区放在另一个卷中，便于独立升级和恢复。

3.2.3 ext4：块设备上的通用选择

ext4 是 Linux 桌面和服务器的事实标准，在嵌入式领域主要用于 eMMC、SD 卡和 SSD。它提供日志（Journal）、扩展属性、多块分配等特性，成熟稳定。但 ext4 并非为 NAND 介质优化，如果直接用于裸 Flash 会因缺乏磨损均衡而快速损坏。在 eMMC 上使用时，ext4 依赖设备内部的 FTL 和磨损均衡算法，因此是安全的选择。

在 Buildroot 中生成 ext4 镜像时，可以指定大小、inode 数量、块大小等参数。对于只读根文件系统，可以关闭日志（tune2fs -O ^has_journal）以减少写放大和延长介质寿命。

3.2.4 F2FS：为 NAND 优化的块设备文件系统

F2FS（Flash-Friendly File System）由三星开发，专为 NAND 闪存设计，但运行在块设备之上。它采用日志结构（Copy-on-Write）设计，将数据按段（Segment）组织，通过多级页表管理元数据，支持灵活的压缩选项。F2FS 在 eMMC 和 SD 卡上的随机写入性能通常优于 ext4，且掉电恢复速度更快。

F2FS 的缺点是内核支持需要较新版本（Linux 3.8+），且部分工具链（如 fsck.f2fs）在 Buildroot 中需要额外启用。对于频繁写入的嵌入式设备（如行车记录仪、工业数据采集器），F2FS 是一个值得考虑的替代方案。

3.2.5 SquashFS：只读压缩文件系统

SquashFS 是嵌入式 Linux 中最常用的只读文件系统。它将整个文件系统压缩为一个镜像，支持多种压缩算法（gzip、lzma、lzo、xz、zstd），解压速度快，适合存放内核模块、应用程序和静态资源。SquashFS 镜像可以放在任意块设备上，也可以嵌入 U-Boot 或内核镜像中。

在 Buildroot 中，SquashFS 通常与 overlayfs 或 tmpfs 配合使用：SquashFS 作为只读底层，overlayfs 将可写层叠加在 tmpfs 或持久化分区上，实现"只读根文件系统 + 可写数据"的经典架构。这种方案既保证了系统完整性（防止误修改），又提供了运行时灵活性。

3.2.6 initramfs：内存中的临时根文件系统

initramfs 是一个基于 cpio 归档的内存文件系统，由内核在启动早期加载到 RAM 中。它通常包含必要的设备驱动、初始化脚本和工具，用于挂载真正的根文件系统。initramfs 的特点是加载速度快、不占用持久存储空间，但所有数据在断电后丢失。

在 Buildroot 中，initramfs 可以作为最终根文件系统（适用于无存储介质的场景），也可以作为过渡阶段（先加载 initramfs，再切换到 ext4/UBIFS）。对于需要快速启动或支持多种存储介质的设备，initramfs 是必不可少的组件。

3.3 选型判断方法：从需求到决策的路径

选型过程应遵循以下步骤：

1. 确定存储介质类型：查看硬件原理图或产品规格书，确认是 NOR、NAND 还是 eMMC/SD。如果是裸 NAND，直接排除 ext4 和 F2FS；如果是 eMMC，排除 UBIFS 和 JFFS2。
2. 评估读写需求：根文件系统是否需要写入？如果只读，优先考虑 SquashFS；如果需要写入，则选择读写文件系统。
3. 考虑掉电安全等级：工业设备、汽车电子对掉电数据完整性要求高，UBIFS 和 F2FS 的日志/检查点机制更可靠；消费类产品可以接受 ext4 的日志恢复。
4. 评估容量和性能：大容量 NAND（256MB 以上）建议 UBIFS；小容量 NOR 用 JFFS2；eMMC 上追求性能选 F2FS，追求兼容性选 ext4。
5. 检查 Buildroot 支持：确认目标架构和内核版本是否包含所需文件系统驱动，以及 Buildroot 的 target 选项是否满足需求。

3.4 实战案例：工业数据采集器的文件系统选型

某工业数据采集器项目，硬件平台采用 NXP i.MX6ULL 处理器，板载 512MB NAND Flash（MLC），需要存储 Linux 内核、根文件系统、应用程序以及采集到的传感器数据。产品要求：7×24 小时连续运行，支持意外断电后数据不丢失，且系统启动时间不超过 10 秒。

初始方案：工程师最初选择 ext4 作为根文件系统，因为团队对 ext4 最熟悉。但在原型测试中发现两个严重问题：一是 ext4 无法直接挂载到 MTD 设备上，需要额外的 mtdblock 驱动，性能极差；二是 MLC NAND 的位翻转导致 ext4 元数据损坏，系统在运行 3 天后无法启动。

分析过程：通过查看内核日志，发现大量 UBI 错误和 ext4 的 checksum 失败。进一步确认，ext4 不具备坏块管理和磨损均衡能力，MLC NAND 的原始误码率（BER）远高于 SLC，必须使用带 ECC 和坏块管理的文件系统。

最终方案：改用 UBIFS 作为根文件系统，数据分区也使用 UBIFS 独立卷。具体操作如下：

# Buildroot 配置
BR2_TARGET_ROOTFS_UBIFS=y
BR2_TARGET_ROOTFS_UBIFS_LEBSIZE=0x1F000
BR2_TARGET_ROOTFS_UBIFS_MINIOSIZE=2048
BR2_TARGET_ROOTFS_UBIFS_MAXLEBCNT=2048

# 内核配置
CONFIG_MTD_UBI=y
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_COMPRESSION=y
CONFIG_UBIFS_FS_ZLIB=y

同时，将内核镜像放在独立的 UBI 卷中，使用 U-Boot 的 UBI 命令加载。数据采集程序通过 POSIX 接口写入 /data 目录，UBIFS 自动处理磨损均衡和掉电恢复。

结果对比：UBIFS 方案下，系统启动时间从 ext4 的 15 秒降至 6 秒（UBIFS 挂载速度快），连续运行 30 天未出现数据损坏。掉电测试 100 次，数据完整率 100%。代价是 UBIFS 的 CPU 占用率比 ext4 高约 5%（压缩和解压），但在 i.MX6ULL 上完全可接受。

复盘经验：选型不能只看文件系统本身的特性，必须结合存储介质类型和硬件 ECC 能力。对于 MLC NAND，UBIFS 是当前最稳妥的选择；如果使用 SLC NAND 且容量较小，JFFS2 也可以胜任。此外，Buildroot 中 UBIFS 的 LEB 大小和最小 I/O 大小必须与 NAND 的页大小和子页大小匹配，否则会挂载失败。

3.5 常见误区与总结

另一个常见误区是忽视 SquashFS 的压缩比。对于包含大量文本、日志模板和静态库的根文件系统，SquashFS 的 zstd 压缩通常能达到 50% 以上的空间节省，这意味着可以选用更小容量的 Flash 芯片，降低 BOM 成本。但要注意，SquashFS 的随机读取性能不如 ext4，如果应用程序频繁读取小文件，需要评估解压开销。

最后，initramfs 不应被当作常规根文件系统使用，因为其容量受限于 RAM 大小，且所有修改在重启后丢失。正确的用法是作为启动过渡层，或者用于无存储介质的极简系统（如网络启动设备）。