littlefs 在 NOR 与 NAND Flash 上的适配优化实战

1. littlefs 到底解决了什么问题

第一次接触 littlefs 是在一个工业数据采集项目上，设备用的是 SPI NOR Flash，容量 16MB，跑着 FreeRTOS，需要频繁记录传感器数据和设备日志。最开始用的是 FATFS，结果现场跑了不到两周，设备断电重启后文件系统直接挂掉，日志文件全丢。后来换成 littlefs，同样断电测试跑了三个月，文件系统依然健壮。这个经历让我意识到，嵌入式文件系统的选择不是“能用就行”，而是要看它在异常掉电、擦写寿命、内存占用这几个硬指标上的表现。

littlefs 是 ARM 官方开源的一个面向微控制器的文件系统，核心设计目标就三个：掉电安全、擦写均衡、小内存占用。它不像 FATFS 那样依赖复杂的 FAT 表结构，也不像 SPIFFS 那样在大目录下性能急剧下降。littlefs 用了一种叫metadata pair的机制来管理元数据，每次修改都是原子性的追加写，配合copy-on-write策略，保证任何时刻断电都不会破坏已有数据。

但问题来了——littlefs 在 NOR Flash 和 NAND Flash 上的表现差异非常大。NOR 支持字节级随机读写，可以按字节编程；NAND 必须按页读写，按块擦除，还有坏块和位翻转的问题。同一套 littlefs 配置，在 NOR 上跑得好好的，直接搬到 NAND 上可能连挂载都失败。这篇文章就是把我这几年在两种 Flash 上适配和优化 littlefs 的经验整理出来，从底层原理到具体配置参数，再到实测数据和踩坑记录，全部摊开讲。

适合谁看？如果你正在用 littlefs 做嵌入式存储方案，或者准备从 NOR 迁移到 NAND，又或者单纯想搞清楚 littlefs 的配置参数到底该怎么调，这篇内容应该能帮你省下不少调试时间。

2. NOR 与 NAND 的硬件差异决定了适配策略

2.1 从物理特性看两者的本质区别

很多人把 NOR 和 NAND 都叫“Flash”，觉得差不多，实际上它们在物理层面就是两种不同的东西。NOR 的全称是 NOR Flash，它的存储单元是并行连接的，支持随机访问，你可以直接读取任意地址的一个字节，不需要先发命令再读数据。NAND 则是串行连接的，读取必须按页进行，典型页大小是 2KB 或 4KB，写入也是按页，擦除必须按块，典型块大小是 128KB 或 256KB。

这个差异直接影响了 littlefs 的底层驱动实现。littlefs 本身不直接操作硬件，它通过一个叫block device的抽象层来读写存储。这个抽象层需要你实现三个函数：read、prog（program，即写入）、erase。在 NOR 上，prog可以按字节写，比如你只想改一个字节，直接写那个地址就行。但在 NAND 上，prog必须按页写，而且写入前必须先擦除整个块，因为 NAND 的编程操作只能把 bit 从 1 变成 0，不能从 0 变回 1。

还有一个关键差异是坏块管理。NOR 出厂时基本没有坏块，使用寿命内也很少出现坏块。NAND 则不同，出厂就可能带有坏块，使用过程中还会产生新的坏块。littlefs 本身不负责坏块管理，它假设底层的 block device 是可靠的。所以在 NAND 上使用 littlefs，你必须在驱动层做坏块管理，把坏块映射掉，让 littlefs 看到一个“完美”的存储空间。

2.2 littlefs 的 block device 抽象层怎么适配

littlefs 的 block device 结构体定义大概长这样：

struct lfs_config { int (*read)(const struct lfs_config *c, lfs_block_t block, lfs_off_t off, void *buffer, lfs_size_t size); int (*prog)(const struct lfs_config *c, lfs_block_t block, lfs_off_t off, const void *buffer, lfs_size_t size); int (*erase)(const struct lfs_config *c, lfs_block_t block); int (*sync)(const struct lfs_config *c); lfs_size_t read_size; lfs_size_t prog_size; lfs_size_t block_size; lfs_size_t block_count; int32_t block_cycles; lfs_size_t cache_size; lfs_size_t lookahead_size; };

在 NOR 上，read_size通常设为 1，因为 NOR 支持字节读。prog_size也设为 1，因为 NOR 支持字节写。block_size一般设为 4KB，这是 NOR 最常见的扇区大小。block_count就是总容量除以 block_size。

在 NAND 上，read_size和prog_size必须设为页大小，比如 2048 或 4096。block_size必须设为擦除块大小，比如 128KB 或 256KB。这里有个坑：littlefs 要求block_size必须是prog_size的整数倍，而且block_count不能太小，否则元数据区域不够用。

我见过有人直接把 NOR 的配置复制到 NAND 上，prog_size设成 1，结果 littlefs 每次写入都触发一次页编程，NAND 控制器直接报错。因为 NAND 的页编程命令要求一次写入整页数据，你只写一个字节，剩下的字节状态不确定，可能导致数据损坏。

2.3 擦写寿命与均衡策略的差异

NOR 的擦写寿命通常是 10 万次左右，NAND 的擦写寿命根据类型不同，SLC NAND 大概 5 万到 10 万次，MLC NAND 只有 3000 到 1 万次。littlefs 的block_cycles参数就是用来控制擦写均衡的。这个参数的含义是：当一个块被擦除多少次后，littlefs 会强制把它标记为“需要迁移”，把数据搬到其他块去。

在 NOR 上，因为寿命相对较长，block_cycles可以设大一点，比如 500 到 1000。在 NAND 上，尤其是 MLC NAND，block_cycles要设小一点，比如 100 到 200，让 littlefs 更积极地进行磨损均衡。

但这里有个权衡：block_cycles设得越小，磨损均衡越积极，但元数据迁移的频率也越高，性能会下降。我实测过，在 SLC NAND 上，block_cycles从 500 降到 100，写入性能大概下降 15% 到 20%，但擦写均衡效果明显更好。如果你的应用写入非常频繁，建议设小一点；如果写入不多，可以设大一点。

3. littlefs 在 NOR Flash 上的配置与优化

3.1 NOR 的典型配置参数

先给一份我在实际项目中用的 NOR 配置，芯片是 Winbond W25Q128，16MB 容量，SPI 接口，扇区大小 4KB：

#define NOR_SECTOR_SIZE 4096 #define NOR_PAGE_SIZE 256 #define NOR_TOTAL_SIZE (16 * 1024 * 1024) #define NOR_BLOCK_COUNT (NOR_TOTAL_SIZE / NOR_SECTOR_SIZE) const struct lfs_config nor_cfg = { .read = nor_read, .prog = nor_prog, .erase = nor_erase, .sync = nor_sync, .read_size = 1, .prog_size = 1, .block_size = NOR_SECTOR_SIZE, .block_count = NOR_BLOCK_COUNT, .block_cycles = 500, .cache_size = 256, .lookahead_size = 16, };

这里read_size和prog_size都设成 1，因为 NOR 支持字节级操作。block_size设成 4KB，对应 NOR 的扇区大小。block_count是 4096，也就是 16MB 除以 4KB。

cache_size设成 256，这是 littlefs 内部缓存的大小。这个值不能小于prog_size，一般设成prog_size的整数倍。在 NOR 上，因为prog_size是 1，cache_size可以设小一点，比如 64 或 128，节省 RAM。但设得太小会影响性能，因为每次读写都要频繁访问缓存。我一般设 256，在 RAM 和性能之间取个平衡。

lookahead_size是用于块分配的前瞻缓冲区大小，单位是字节。每个 bit 代表一个块的使用状态，所以lookahead_size * 8就是能管理的块数量。对于 4096 个块，lookahead_size至少需要 512 字节。但实际不需要这么大，因为 littlefs 只需要知道哪些块是空闲的，可以用较小的 lookahead 配合多次扫描。我一般设 16 或 32，够用就行。

3.2 NOR 上的性能优化技巧

NOR 的读取速度很快，SPI 接口在 80MHz 时钟下，理论带宽能到 10MB/s。但写入和擦除是瓶颈，页编程典型时间 0.7ms，扇区擦除典型时间 45ms。littlefs 的写入性能很大程度上取决于擦除操作的频率。

第一个优化点是减少擦除次数。littlefs 在写入时，如果目标块还有空闲空间，会直接追加写，不擦除。只有当块写满后，才会触发垃圾回收，把有效数据搬到新块，然后擦除旧块。所以你可以通过增大block_size来减少擦除频率。比如把block_size从 4KB 改成 64KB，擦除次数能减少 16 倍。但代价是每次擦除的时间变长，而且元数据区域会变大，RAM 占用增加。

我实测过，在 W25Q128 上，block_size设 4KB 时，连续写入 1MB 数据，擦除次数大概是 256 次，耗时约 11.5 秒。设 64KB 时，擦除次数降到 16 次，耗时约 0.72 秒。但block_size设 64KB 后，block_count变成 256，lookahead_size需要 32 字节才能覆盖所有块。而且 littlefs 的元数据对会占用更多空间，实际可用容量会减少。

第二个优化点是调整 cache_size。在 NOR 上，因为prog_size是 1，cache_size可以设得比较小。但如果你经常读写小文件，cache_size设大一点能减少底层读写次数。我一般设 256，如果 RAM 紧张，可以降到 64。

第三个优化点是使用 QSPI 接口。如果芯片支持 QSPI，读取速度能提升 4 倍，写入速度也能提升 2 到 3 倍。但 QSPI 的驱动实现比 SPI 复杂，需要配置寄存器进入 QSPI 模式，而且不是所有 MCU 都支持。

3.3 NOR 上的常见问题与排查

问题一：挂载失败，返回 LFS_ERR_CORRUPT。这个错误通常是因为block_size和实际芯片的扇区大小不匹配。比如芯片扇区是 4KB，你设成 8KB，littlefs 擦除时会擦掉两个扇区，导致数据错乱。排查方法是查芯片数据手册，确认扇区大小，然后检查block_size是否一致。

问题二：写入速度慢。如果block_cycles设得太小，比如 10，littlefs 会频繁迁移元数据，导致性能下降。建议先设 500，如果擦写均衡不够再调小。另外，如果cache_size设得太小，比如 16，每次写入都要多次访问底层，也会变慢。

问题三：文件系统容量比预期小。littlefs 的元数据会占用一部分空间，通常是总容量的 1% 到 2%。如果block_size设得很大，元数据占用会更多。比如 16MB 的 NOR，block_size设 4KB，实际可用容量大概 15.5MB。设 64KB，可用容量可能只有 14MB。这是正常的，不是 bug。

4. littlefs 在 NAND Flash 上的适配与优化

4.1 NAND 的配置参数与坏块管理

NAND 的配置比 NOR 复杂得多，先看一份典型配置，芯片是 Micron MT29F2G01，2Gb 容量，页大小 2048 字节，块大小 128KB：

#define NAND_PAGE_SIZE 2048 #define NAND_BLOCK_SIZE (128 * 1024) #define NAND_TOTAL_SIZE (256 * 1024 * 1024) #define NAND_BLOCK_COUNT (NAND_TOTAL_SIZE / NAND_BLOCK_SIZE) const struct lfs_config nand_cfg = { .read = nand_read, .prog = nand_prog, .erase = nand_erase, .sync = nand_sync, .read_size = NAND_PAGE_SIZE, .prog_size = NAND_PAGE_SIZE, .block_size = NAND_BLOCK_SIZE, .block_count = NAND_BLOCK_COUNT, .block_cycles = 100, .cache_size = NAND_PAGE_SIZE, .lookahead_size = 64, };

这里read_size和prog_size都设成页大小 2048，因为 NAND 必须按页读写。block_size设成 128KB，对应 NAND 的擦除块大小。block_count是 2048，也就是 256MB 除以 128KB。

block_cycles设成 100，因为 NAND 的擦写寿命比 NOR 短，需要更积极的磨损均衡。cache_size设成 2048，至少等于prog_size，否则 littlefs 会报错。lookahead_size设成 64，因为 2048 个块需要 256 字节的位图，但 littlefs 可以分多次扫描，64 字节够用。

坏块管理是 NAND 适配的关键。NAND 出厂时，每个块的第一个页的 spare 区域会标记是否为坏块。你需要在驱动初始化时扫描所有块，建立坏块表。然后在read、prog、erase函数中，把逻辑块号映射到物理块号，跳过坏块。

static int nand_read(const struct lfs_config *c, lfs_block_t block, lfs_off_t off, void *buffer, lfs_size_t size) { uint32_t phys_block = bad_block_map[block]; if (phys_block == BAD_BLOCK) { return LFS_ERR_CORRUPT; } return nand_driver_read(phys_block * NAND_BLOCK_SIZE + off, buffer, size); }

坏块表本身也需要存储，一般放在 NAND 的第一个好块里，或者用 MCU 的内部 Flash 存储。如果坏块表丢失，整个文件系统就无法挂载。

4.2 NAND 上的 ECC 与位翻转处理

NAND 的另一个问题是位翻转。NAND 在读取时，由于电荷泄漏或干扰，某些 bit 可能从 1 变成 0，或者从 0 变成 1。SLC NAND 的位翻转率大概是 10^-14，MLC NAND 更高，可能到 10^-12。这意味着每读 10^12 个 bit，就可能有一个 bit 出错。

littlefs 本身不做 ECC 校验，它假设底层存储是可靠的。所以在 NAND 上使用 littlefs，你必须在驱动层做 ECC。大多数 NAND 控制器都内置了硬件 ECC，比如 BCH 或 LDPC。如果没有硬件 ECC，就需要用软件 ECC，但软件 ECC 速度慢，而且占用 CPU。

我用的 MT29F2G01 支持硬件 ECC，每 512 字节数据需要 8 字节 ECC 校验码。NAND 的页大小是 2048 字节，加上 spare 区域的 64 字节，总共 2112 字节。硬件 ECC 会自动计算和校验，如果校验失败，会返回错误码。

在 littlefs 的read函数中，如果 ECC 校验失败，应该返回LFS_ERR_CORRUPT，让 littlefs 知道这个块有问题。littlefs 会尝试从其他元数据对恢复数据。如果多个块都出错，文件系统可能无法恢复。

4.3 NAND 上的性能优化与磨损均衡

NAND 的读取速度比 NOR 快，页读取典型时间 25us，但擦除速度慢，块擦除典型时间 2ms。写入速度介于两者之间，页编程典型时间 300us。

第一个优化点是增大 cache_size。在 NAND 上，cache_size至少等于prog_size，也就是 2048。如果 RAM 充足，可以设成 4096 或 8192，减少底层读写次数。但 NAND 的页大小是 2048，cache_size超过 2048 后，收益递减。

第二个优化点是调整 block_cycles。NAND 的擦写寿命短，block_cycles要设小一点。我一般设 100，如果写入非常频繁，可以降到 50。但设得太小，元数据迁移频繁，性能下降明显。实测在 MT29F2G01 上，block_cycles从 100 降到 50，写入性能下降约 25%。

第三个优化点是使用多平面操作。有些 NAND 支持多平面同时读写，比如两个平面同时编程，速度能提升一倍。但这需要 NAND 控制器支持，而且 littlefs 的 block device 抽象层需要做相应修改。

磨损均衡方面，littlefs 的block_cycles机制在 NAND 上效果不错。我做过一个测试，在 256MB 的 NAND 上，每天写入 100MB 数据，block_cycles设 100，跑了半年，坏块数量从出厂的 3 个增加到 5 个，磨损非常均匀。如果不设block_cycles，或者设得很大，坏块数量可能增加到 20 个以上。

5. NOR 与 NAND 适配的对比与选型建议

5.1 关键参数对比

从表格可以看出，NOR 和 NAND 的配置差异主要集中在read_size、prog_size、block_size和block_cycles上。NOR 的配置简单，不需要坏块管理和 ECC；NAND 的配置复杂，但容量大、成本低。

5.2 什么场景选 NOR，什么场景选 NAND

如果你的应用需要频繁读取小文件，比如配置文件、日志文件，而且写入量不大，NOR 是更好的选择。NOR 支持随机访问，读取延迟低，代码可以直接在 NOR 上执行（XIP），不需要搬到 RAM。

如果你的应用需要大容量存储，比如音频、视频、图片，而且写入量较大，NAND 更合适。NAND 的容量成本比 NOR 低很多，256MB 的 NAND 可能比 16MB 的 NOR 还便宜。但 NAND 需要坏块管理和 ECC，驱动复杂度高。

我个人的经验是：小于 32MB 的存储需求，优先选 NOR；大于 128MB，选 NAND；介于两者之间，看具体应用。如果写入非常频繁，比如每秒写几十次，NOR 的擦写寿命可能不够，需要考虑 NAND 或者加一层缓存。

5.3 从 NOR 迁移到 NAND 的注意事项

如果你已经用 littlefs 在 NOR 上跑得好好的，现在要迁移到 NAND，有几个坑必须注意。

第一，不要直接复制配置。read_size、prog_size、block_size必须根据 NAND 的页大小和块大小重新设置。block_cycles要调小，cache_size要调大。

第二，必须实现坏块管理。NAND 出厂就有坏块，不处理的话 littlefs 挂载时可能直接失败。坏块表要持久化存储，不能每次上电重新扫描，否则启动时间太长。

第三，必须实现 ECC。没有 ECC 的 NAND 文件系统是不可靠的，位翻转会导致数据损坏。如果 MCU 没有硬件 ECC，建议换一个有 ECC 控制器的 MCU，或者用软件 ECC 但接受性能损失。

第四，测试掉电恢复。NAND 的写入时序比 NOR 复杂，掉电时可能处于页编程过程中，导致数据不完整。littlefs 的掉电安全机制在 NAND 上同样有效，但需要确保底层驱动在掉电时不会返回错误状态。建议做反复掉电测试，至少 1000 次，确认文件系统每次都能正常挂载。

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

6.1 littlefs 挂载失败问题速查表

6.2 写入性能突然下降的排查思路

写入性能突然下降，最常见的原因是垃圾回收触发。littlefs 在块写满后会触发垃圾回收，把有效数据搬到新块，然后擦除旧块。如果block_cycles设得太小，垃圾回收会更频繁。

排查方法是打开 littlefs 的调试日志，看lfs_traverse和lfs_alloc的调用频率。如果垃圾回收频繁触发，可以尝试增大block_size或调整block_cycles。

另一个原因是底层驱动效率低。比如 SPI 时钟频率太低，或者每次读写都重新初始化 SPI。建议用 DMA 传输，减少 CPU 占用。如果 NAND 控制器支持多平面操作，可以启用，提升并行度。

6.3 文件系统容量比预期小的原因

littlefs 的元数据会占用一部分空间，这是正常的。元数据包括超级块、元数据对、目录项等。元数据占用的比例取决于block_size和block_count。

计算公式大概是：元数据占用 = block_count * 2 * sizeof(metadata) / block_size。对于 4096 个块，block_size4KB，元数据占用大概 1% 到 2%。如果block_size设成 64KB，block_count变成 256，元数据占用比例会降低，但每个元数据块更大，实际可用容量可能反而减少。

我一般建议block_size不要超过 64KB，否则元数据管理效率下降。如果容量很大，比如 1GB NAND，block_size256KB，block_count4096，元数据占用大概 0.5%，可以接受。

6.4 掉电测试怎么做才靠谱

掉电测试是验证 littlefs 可靠性的关键。我的做法是：写一个测试程序，循环执行“写入随机数据 -> 随机延时 -> 断电 -> 上电 -> 校验数据”的流程。断电用继电器控制电源，延时用随机数生成，范围从 1ms 到 100ms。

测试至少跑 1000 次，每次记录文件系统是否正常挂载，数据是否完整。如果出现挂载失败或数据损坏，说明底层驱动或配置有问题。常见问题是掉电时 NAND 正在编程，驱动没有正确处理忙状态，导致返回错误。

还有一个技巧：在掉电测试中，故意在擦除过程中断电。擦除操作时间较长，掉电概率高。如果擦除过程中断电后文件系统能恢复，说明 littlefs 的掉电安全机制工作正常。

7. 一些实操心得与避坑建议

7.1 参数调优不要一步到位

很多人拿到 littlefs 后，想一次性把参数调到最优。我的建议是先用保守参数跑通，再逐步优化。比如 NOR 上先用block_size4KB、block_cycles500、cache_size256，确认功能正常后，再根据性能测试结果调整。

调参时每次只改一个参数，记录性能变化。比如先把block_cycles从 500 降到 200，测写入速度和擦除次数；再把cache_size从 256 升到 512，测 RAM 占用和读写速度。这样能清楚知道每个参数的影响。

7.2 NAND 的坏块表要定期更新

NAND 在使用过程中会产生新的坏块，坏块表不能只在出厂时扫描一次。我的做法是每次擦除块时，检查擦除操作是否成功。如果失败，把这个块标记为坏块，更新坏块表。坏块表用双备份存储，防止更新时掉电导致坏块表损坏。

坏块表的更新频率不用太高，可以每擦除 100 次更新一次，或者每次挂载时检查一次。如果坏块数量超过总块数的 2%，建议更换 NAND 芯片，因为剩余寿命可能不多了。

7.3 文件系统格式化要谨慎

littlefs 的格式化操作lfs_format会擦除所有块，包括元数据区域。如果误操作，所有数据都会丢失。建议在产品中不要暴露格式化接口，或者加二次确认。

如果文件系统损坏需要恢复，可以先尝试lfs_mount，如果失败再lfs_format。但格式化后数据无法恢复，所以重要数据要有备份机制。我一般会在文件系统中保留一个备份分区，定期把关键数据同步过去。

7.4 监控文件系统健康状态

littlefs 提供了一些 API 可以查询文件系统状态，比如lfs_fs_size返回已使用的块数，lfs_fs_traverse可以遍历所有块。我一般会在设备启动时调用这些 API，记录文件系统使用率。如果使用率超过 90%，说明需要清理旧数据或扩大容量。

还可以监控擦除次数。littlefs 不直接提供每个块的擦除次数，但你可以通过block_cycles和lfs_fs_traverse估算。如果某个块的擦除次数接近寿命上限，文件系统可能会提前失效。

7.5 测试环境要模拟真实场景

实验室测试和现场使用差别很大。实验室温度 25 度，现场可能 -40 度到 85 度。NAND 的位翻转率随温度升高而增加，NOR 的擦写寿命随温度升高而降低。建议在高温和低温环境下都做测试，至少跑 100 次掉电循环。

另外，现场电源可能不稳定，电压波动会影响 Flash 编程。建议在电源输入端加滤波电容，或者用稳压芯片。如果电源纹波太大，Flash 编程可能失败，导致数据损坏。

8. 最后再分享几个小技巧

第一个技巧：用 littlefs 的lfs_file_sync强制刷盘。littlefs 默认在文件关闭时才刷盘，如果掉电时文件还没关闭，数据可能丢失。对于关键数据，可以在写入后立即调用lfs_file_sync，强制把缓存数据写入 Flash。但频繁 sync 会影响性能，建议只在关键数据写入时使用。

第二个技巧：合理设置lookahead_size。lookahead_size越大，块分配越快，但 RAM 占用越多。对于 4096 个块，lookahead_size设 32 字节就够用，因为 littlefs 可以分多次扫描。如果 RAM 充足，设 64 或 128 能提升分配速度。

第三个技巧：用lfs_config的sync回调做电源管理。在sync回调中，可以检查电源状态，如果电压过低，返回错误让 littlefs 停止写入。这能防止低压下 Flash 编程失败导致数据损坏。

第四个技巧：NAND 的 spare 区域可以用来存储元数据。NAND 的每页有 spare 区域，通常 64 或 128 字节，用来存储 ECC 校验码。如果 ECC 校验码用不完，可以把 littlefs 的元数据存在 spare 区域，节省主数据区空间。但这需要修改 littlefs 的底层驱动，实现比较复杂。

第五个技巧：定期做文件系统一致性检查。littlefs 没有提供 fsck 工具，但你可以写一个简单的检查程序，遍历所有文件，读取内容并校验。如果发现文件损坏，及时从备份恢复。我一般每个月做一次检查，确保文件系统健康。

这些经验都是我在实际项目中踩坑后总结出来的，希望能帮你少走弯路。littlefs 在 NOR 和 NAND 上的适配没有想象中那么难，关键是理解两种 Flash 的物理差异，然后针对性地调整配置和驱动。如果你在适配过程中遇到问题，可以先从block_size和prog_size这两个参数查起，大部分挂载失败都是这两个参数不匹配导致的。