一句话结论：嵌入式文件系统的难点从来不是「把文件存进去」，而是在介质物理特性受限的前提下，保证掉电后数据仍可恢复、把擦写次数花在真正需要的地方。NOR 的扇区大、擦除慢、寿命十万次量级，NAND 的页小、擦除快、需要坏块与 ECC，eMMC 有内部 FTL 与磨损均衡——三套介质特性直接决定了三套不同的文件系统设计。选错抽象层，写放大能从 1 倍放大到 10 倍以上；漏掉掉电原子性，一次掉电就是一批配置全丢。

这份文档解决什么

本文是文件系统层的专项指南：从介质物理特性出发，讲清分区挂载、FTL 映射与垃圾回收、FAT 族结构、日志式一致性模型、LittleFS 与 SPIFFS 的取舍、键值存储布局、磨损均衡与寿命预算、掉电原子性、加密存储，最后给出一套可执行的移植流程与验收规范。 存储器件的电气设计（时序、电压、封装、信号完整性）由各器件的电路设计指南承接；内核设备树、内核态驱动开发由《Linux 内核开发指南（BSP Kernel）》承接；具体 Flash 芯片的驱动实现由《SPI NOR / SPI NAND / PPI NAND / eMMC 驱动开发指南》系列承接。本文站在它们之上，只讲文件系统。

读者路径

版本基线与引用约定

• 文件系统以 Linux 6.1 / 5.15 LTS 与 LittleFS v2.9 / v3.x、SPIFFS 3.0 为基线；
• 介质参数以各厂商数据手册为唯一依据，本文数值仅为示例量级，实际设计必须回到手册；
• 命令与路径在 MCU 上为 /mnt、/data 等挂载点，在 Linux 上为 /dev/mmcblk0p1 等块设备，两套都给出；
• 寄存器级时序参数见《SPI NOR / eMMC 电路设计指南》，本文只讲它们对文件系统软件栈的影响。

1 · 文件系统全景与选型

文件系统是软件栈里最容易被「当成系统自带」的一层，却是嵌入式产品里最容易出问题的一层。它的复杂度不来自代码量，而来自它要对物理世界的三条硬约束负责。

1.1 为什么嵌入式文件系统是独立课题

PC 上的文件系统几乎不需要工程师操心，因为三个前提天然成立：介质块大（4 KB 扇区起步）、可靠性高（SSD 有自己的 FTL 与磨损均衡）、应用层只管调 API。嵌入式把这三个前提全部拿掉了。

一颗 64 Mb SPI NOR 的擦除粒度可能是 4 KB，一个页写 200 ms；一次改 16 字节的配置文件，底层要读出整块、修改、擦除、写回——写放大 256 倍。一块 1 Gb 的 NAND 页只有 2 KB、使用中还会长出坏块，需要自己的坏块表与 ECC 策略。这些约束直接进文件系统设计，不是加个驱动就完事。

1.2 五层抽象：应用、FS、FTL、块设备、介质

上图是选型的起点。下面逐层说明每层负责什么、边界在哪里。

第 1 层：应用与框架

业务代码、日志服务、配置中心、数据库。这一层只应该看到 POSIX 接口（open/read/write/lseek/fsync）。如果应用需要知道自己在 NOR 上还是在 eMMC 上，说明抽象已经漏了——那是最需要警惕的设计信号。

第 2 层：文件系统

本文的主体。它负责五件事：

• 空间分配：哪些块归哪个文件、哪些块空闲；
• 目录组织：文件名到数据块的映射；
• 元数据管理：超级块、位图、目录项、inode 的可靠性；
• 一致性：保证掉电后能恢复到某个一致状态；
• 寿命与配额：把有限的擦写次数分配给无限的写入请求。

第 3 层：FTL（闪存转换层）

把「逻辑块地址」翻译成「物理页地址」，并在逻辑页被改写时做垃圾回收。eMMC 与 SD NAND 芯片内部自带 FTL，用户态看到的是一个干净的块设备；SPI NOR 与裸 NAND 则通常需要在主机侧自己实现。第 4 章专门讲。

第 4 层：块设备层

提供统一的扇区语义：request(sector, count, buffer)。Linux 上是 blkdev / mtdblk / mmcblk；MCU 上由应用自己实现这个函数指针。关键约定是：单位是 512 字节还是页大小，必须在设计时定死，混用是移植里最常见的错误之一。

第 5 层：物理介质

这三条规则是整篇文档的地基。请记住它们的实际后果：

• 「擦除只能整块」→ 文件系统的最小分配单元不能小于擦除粒度，否则每次写都要擦一个大盘；
• 「编程有顺序性」→ NAND 上必须有 FTL，NOR 上可以不写 FTL 但要用日志式结构；
• 「断电即最终」→ 一切跨块操作都需要事务性设计。

1.3 块设备与字符设备的分界

这个分界决定了「能否用文件系统」，实践中要先问清楚。

实践中最容易踩的一条：在 SPI NOR 上用 mtdblock 挂文件系统，写放大会大到不可接受。因为 MTD 的写是「按最小可写单位（NAND 上是页、NOR 上是 1 字节）」，而擦除是「按擦除单位（4 KB ~ 256 KB）」。文件系统以为自己在改 1 KB，实际触发了一次 64 KB 的擦除。正确路径是让文件系统直接跑在 MTD 之上（LittleFS 就是这么设计的），由它把「改了多少」与「擦多少」的关系算清楚。

1.4 本文覆盖范围与前置约定

2 · 存储介质与硬件基础

这一章看起来像是「硬件内容」，但它是文件系统设计的输入。跳过这一章直接抄一个文件系统跑起来，是绝大多数移植失败的起点。

2.1 NOR、NAND 与 eMMC 的本质差异

三类介质的差异可以归到三条根上：能否原地改写、擦除粒度多大、会不会长坏块。

三点最容易被忽略：

• NOR 也有坏块，只是出厂时就标好了、增长极慢。但 NOR 的「坏块」一般不是整块不可用，而是某些位在擦除后无法归 1。厂家会在出厂时扫描并标记，文件系统要尊重这个标记，不能随意擦除被标记的块。
• NAND 的 OOB 空间是生命线。它不只放 ECC，还放坏块标记与 FTL 映射信息。写 OOB 时必须严格遵守「只允许把 1 写成 0」的规则，否则映射表会静默损坏。
• eMMC 的 TBW 指标才是真正该看的参数。它直接给出「在标称负载下能写多少 TB」，比「擦除次数 × 容量」更贴近实际。但要注意 TBW 是按厂商自己的负载模型测的，若你的负载是高频小写入，寿命会明显短于 TBW 标称。

2.2 擦除粒度与编程粒度

这两个参数决定文件系统「最小分配单元」的下限，也决定了一致性原语的可用粒度。

另一个常见坑是「擦除时间取典型值而非最大值」。典型值 200 ms 的器件，最大值可能 2 s。忙等按典型值设超时，遇到坏块（擦除慢）就误判失败；按最大值设，正常时只是多等几轮，不影响正确性。超时一律按数据手册的最大值设定。

2.3 寿命、写入放大与磨损均衡

图 4 给出的算例说明：寿命是三者相乘的结果。介质寿命是分子，写放大是分母，使用方式是系数的来源。工程上真正能动的只有两个：降低写放大、改善使用方式。

2.4 掉电行为的物理本质

图 5 的三种形态里，第三种最危险：文件系统的元数据说「文件有 4 KB」，实际内容却是旧的或半新半旧的。程序读到「长度合法但内容错误」的数据，不会报错、静默往下走，最终以诡异的方式崩溃。

工程上对掉电的处理遵循一条原则：介质只保证「单次编程的原子性」，跨块原子性必须由文件系统用「日志」或「双写元数据」自己造出来。第 6 章与第 10 章分别讲机制与工程落地。

2.5 从介质参数反推文件系统设计

这张图建议在移植前填成一张表，逐行确认。顺序上先做介质参数表（照抄手册），再逐条确定文件系统侧的后果，两者对齐后再动手写配置。反过来——先抄一份 CONFIG_LITTLEFS=y 再去想为什么挂了——是嵌入式里最常见的顺序错误。

3 · 分区、挂载与命名空间

分区解决「一块介质怎么切成多块用」，挂载解决「多块怎么变成一棵目录树」。这一章的内容在 PC 上很少被关心，但在嵌入式上每一处都会影响寿命与可靠性。

3.1 分区表：MBR、GPT 与固定分区

三种分区方式并存，选哪种取决于介质类型与平台能力。

固定分区：MCU 上的默认选择

MCU 平台没有 GPT 工具链，常见做法是把分区写进设备树：

&flash0 {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0x0000C000>;   /* 48 KB 引导 */
        };
        storage_partition: partition@c000 {
            label = "storage";
            reg = <0x0000C000 0x00314000>;   /* 3.1 MB 文件系统 */
        };
    };
};

3.2 挂载点与挂载选项

图 9 右侧的六个问题按顺序排查，九成以上的挂载失败在前四个就能定位。

3.3 挂载顺序与依赖关系

挂载顺序错了会表现为「偶发启动失败」——因为根文件系统所在的分区还没挂上，init 就去读它配置。

在 systemd 体系下，挂载顺序由 fstab 的依赖与 unit 的 After= 声明保证；在 BusyBox initramfs 里则要手工按上表顺序写 mount。一条实用的自检规则：把上面这张表做成脚本，逐项检查挂载点是否存在且挂载类型正确，作为开机自检的第一项。

3.4 只读挂载与 rootfs 切换

只读根的四条收益在第 6 章还会再展开：

• 系统文件不可被应用写坏——写坏了重启即可，不需要重刷；
• 写放大只落在小块可写区——boot 与 rootfs 变成一次性写入；
• 升级 = 替换只读镜像——配合 A/B 分区实现原子回滚；
• 安全启动校验对象不被运行时污染——校验的是只读镜像，攻击者改不动。

3.5 tmpfs、ramfs 与内存文件系统

4 · FTL 与闪存转换层

FTL 是「块设备」与「闪存物理特性」之间的翻译器。它决定了文件系统看到的块设备有多「干净」，也决定了寿命被消耗得有多快。

4.1 FTL 要解决的核心问题

一句话：把「可随机覆盖的块」伪装成「只能顺序写的页」。具体要解决四件事。

4.2 逻辑块与物理页的映射结构

图 11 的上半部分是映射本身：逻辑上连续的页，在物理上可以散布在整个芯片。这正是「顺序写」能高效的前提——GC 只需要搬数据，不需要原地改。

下半部分是三张必备表。其中映射表的存放位置是掉电安全的核心，图中的三种方案各有取舍：

4.3 垃圾回收的三种策略

三种策略的差别本质上是「写延迟稳定性」与「平均效率」之间的取舍。对嵌入式产品，评价标准通常不是平均吞吐，而是最坏情况下的写延迟——因为一次超长的 GC 停顿可能直接触发看门狗或用户可感知的卡顿。

4.4 坏块管理与备用块池

坏块处理的核心原则是「宁可少一块，不能用坏块」。一条坏块的错误处理如果不当（比如反复重试到超时才标记），会浪费大量时间并可能扩大损伤。

4.5 FTL 的一致性保证

FTL 层面的掉电一致性问题与文件系统正交但相关。掉电可能发生在 GC 的任意一步：

/* GC 的四个阶段与掉电后的可恢复性 */
1. 选择牺牲块 V（有效页最少）
2. 把 V 中有效页复制到空闲页 P        <- 掉电：V 与 P 同时存在，重复占用空间但可恢复
3. 更新映射表，把逻辑页指向 P       <- 掉电：映射表未更新，数据仍在 V，可重做
4. 标记 V 无效，加入空闲块池       <- 掉电：V 未标记，下次 GC 会重做，不丢数据

关键：第 3 步的映射表更新必须是「原子提交」，
     否则会出现「映射指向 P，但 P 里数据没写完」的错误指针。