当前位置：首页 > news >正文

嵌入式存储性能优化：从eMMC到Raw NAND的软件策略与实战

news 2026/8/23 3:32:23

1. 项目缘起：一次存储性能瓶颈的深度复盘

去年，我接手了一个嵌入式项目的性能优化任务。项目基于一款主流工业级SoC，主控性能尚可，但系统在频繁读写小文件时，响应速度会急剧下降，甚至出现卡顿。最初的存储方案是板上集成的eMMC 5.1，容量32GB。在排查了CPU负载、内存占用和任务调度后，所有矛头都指向了存储I/O。我们用iostat工具监控，发现即使在轻负载下，eMMC的await（平均I/O等待时间）也经常飙升至几十毫秒，这在一个实时性要求不高的管理系统中也显得难以接受。

这个现象促使我开始重新审视嵌入式系统的存储选型与软件策略。我们习惯性地认为eMMC是“嵌入式存储的终点”，因为它集成度高、使用简单。但这次踩坑让我意识到，从eMMC到更底层的NAND Flash，中间隔着巨大的软件优化空间。eMMC的本质是一个“黑盒”，它把NAND介质、控制器和FTL（闪存转换层）封装在一起，提供了块设备接口。这种便利性是以牺牲我们对底层性能的精细控制为代价的。当你无法穿透这个黑盒时，很多优化手段就无从谈起。

因此，这次探讨的核心，不是简单地比较eMMC和NAND谁好谁坏，而是聚焦于当你的系统遇到存储瓶颈时，如何通过软件层面的策略，最大限度地压榨现有硬件的性能，并为可能的存储介质迁移（如从eMMC转向Raw NAND+自研FTL）做好技术储备。无论你是坚守eMMC，还是计划使用SPI NAND、并行NAND，文中的思路和策略都具有普适的参考价值。

2. 理解存储栈：eMMC的便利与NAND的挑战

要谈优化，必须先理解你正在打交道的对象。嵌入式系统的存储栈是一个分层模型，越往上越抽象、越易用，越往下越具体、控制力越强。

eMMC（嵌入式多媒体卡）处于这个栈的中间偏上位置。你可以把它理解为一个“交钥匙”的存储解决方案。芯片内部集成了NAND Flash存储阵列、一个微控制器（负责坏块管理、磨损均衡、ECC校验、垃圾回收等FTL功能）以及一个标准接口控制器（遵循eMMC协议）。对软件开发者而言，它呈现为一个标准的、可寻址的块设备（比如/dev/mmcblk0）。操作系统通过MMC子系统驱动与之通信，所有的复杂操作都在芯片内部完成。

这种架构的优势显而易见：

开发简单：无需关心NAND的特性，像操作硬盘一样操作它。
可靠性由厂商保障：内置的ECC、坏块管理算法经过验证。
接口标准化：遵循JEDEC标准，驱动成熟。

但其劣势正是我们性能瓶颈的根源：

黑盒操作：FTL算法不可知，无法针对特定访问模式优化。
固定配置：缓存策略、缓存大小、命令队列深度等通常不可调或调整范围有限。
额外开销：协议封装、内部管理操作都会带来延迟。

Raw NAND Flash则处于存储栈的底部。它是最原始的存储介质，软件需要直接面对其物理特性：

读写单位不对称：读和写的基本单位是“页”（Page，通常4KB, 8KB, 16KB），但擦除的基本单位是“块”（Block，一个块包含数十到数百个页）。这意味着改写一个页，需要先擦除整个块，再将有效数据拷贝回，这就是“写放大”问题的根源。
寿命有限：每个存储单元有擦写次数限制（P/E Cycle）。
会出错：需要软件实现ECC校验与纠错。
存在坏块：出厂即有或在生命周期内产生，需要管理。

直接使用Raw NAND是极其困难的，因此我们需要在软件栈中引入FTL（Flash Translation Layer）和MTD（Memory Technology Device）子系统。FTL负责将块设备的逻辑地址映射到NAND的物理地址，并处理坏块管理、磨损均衡、垃圾回收等。MTD则为Linux内核提供了一个访问原始闪存设备的统一抽象层。

从eMMC切换到Raw NAND，意味着我们将FTL从芯片内部搬到了主机侧，从“黑盒”变成了“白盒”。这带来了巨大的挑战，但也开启了深度优化的可能性。

3. 针对eMMC的软件优化策略：在黑盒外做文章

当你暂时无法更换硬件，或者产品已经定型使用eMMC时，以下软件策略可以帮助你显著提升存储性能。

3.1 文件系统选型与调优：第一道性能闸门

文件系统是应用程序与块设备之间的桥梁，其设计对性能影响巨大。

Ext4 vs. F2FS：这是最经典的抉择。Ext4是为磁盘设计的日志文件系统，日志机制（Journaling）在意外断电时能保证数据一致性，但会带来额外的写操作（数据可能被写入两次）。对于eMMC，这加剧了写入放大和磨损。F2FS（Flash-Friendly File System）则是专为NAND类存储设计的。它采用日志结构（Log-structured），写入更连续，能减少垃圾回收压力，并具有更好的碎片整理策略。在我们的测试中，对于小文件随机写密集型场景，F2FS的性能相比Ext4有30%-200%的提升。如果你的应用写操作多，特别是随机小文件写，F2FS是首选。
注意：F2FS在空间接近写满时性能下降可能比Ext4更剧烈，需要合理规划分区使用率，建议预留20%以上空间。
关键挂载参数：
- noatime/relatime：默认情况下，每次读取文件都会更新其访问时间戳（atime），这意味着一次读操作会触发一次写操作。noatime完全禁止此更新，relatime仅在访问时间早于修改时间或状态改变时间时才更新。务必在挂载时加上noatime，这对减少无用写入、提升读性能效果立竿见影。
- data=ordered/data=writeback：这是Ext4的日志模式。ordered（默认）只对元数据记日志，保证数据在元数据提交前已落盘，安全性高。writeback也对元数据记日志，但不保证数据写入顺序，性能更高，但断电可能丢失部分最新数据。在允许一定数据丢失风险的场景（如临时文件、缓存）可考虑writeback。
- discard：在线TRIM。让文件系统在删除文件时主动通知eMMC哪些块可回收。但不建议在eMMC上使用，因为TRIM命令可能引发芯片内部耗时的垃圾回收操作，导致命令延迟激增。更好的做法是定期（如每周）通过fstrim命令离线执行。

示例：优化的 /etc/fstab 条目

# 对于Ext4根文件系统 /dev/mmcblk0p2 / ext4 defaults,noatime,errors=remount-ro 0 1 # 对于F2FS数据分区 /dev/mmcblk0p3 /data f2fs defaults,noatime 0 2

3.2 I/O调度器与队列深度：疏通数据管道

Linux内核的I/O调度器决定了块设备上I/O请求的合并、排序和派发策略。eMMC驱动通常使用mmc块设备驱动，其对应的请求队列可以调整。

调度器选择：
- mq-deadline：适用于低速存储设备（如eMMC、SD卡）。它为请求设置截止时间，防止饿死，能提供较好的整体延迟确定性。
- none(Noop)：简单的FIFO队列，不进行任何排序。在本身具有强大内部调度能力的SSD或eMMC上，有时性能更好，因为它减少了主机侧的调度开销。对于eMMC，建议优先测试mq-deadline和none的性能差异。
```
# 查看当前调度器 cat /sys/block/mmcblk0/queue/scheduler # 临时切换为mq-deadline echo mq-deadline > /sys/block/mmcblk0/queue/scheduler
```
调整队列深度：队列深度决定了有多少个I/O请求可以同时发给设备。深度太浅，无法充分利用设备并行性；太深，可能增加延迟。eMMC的默认队列深度可能偏保守。
```
# 查看当前队列深度 cat /sys/block/mmcblk0/queue/nr_requests # 尝试增大（例如从128增到256），需测试验证 echo 256 > /sys/block/mmcblk0/queue/nr_requests
```
实操心得：通过fio工具，在模拟实际负载（如4K随机写）下，测试不同调度器和队列深度的组合，观察IOPS和延迟。变化可能很微妙，但对于密集型负载，找到最优组合能带来5%-15%的性能提升。

3.3 应用层缓存与写入策略：减少对存储的直接冲击

这是最有效、也最容易被忽视的优化点。很多性能问题不是存储设备太慢，而是应用访问模式太“不友好”。

充分利用内存缓存：
- 对于读多写少的配置数据、资源文件，考虑在应用启动时一次性加载到内存中。
- 使用内存文件系统（tmpfs）存放临时文件、Socket文件、PID文件等。将/tmp、/var/run挂载为tmpfs能彻底消除对这些路径的物理I/O。
```
# 在 /etc/fstab 中 tmpfs /tmp tmpfs defaults,noatime,size=100M 0 0 tmpfs /var/run tmpfs defaults,noatime,size=20M 0 0
```
合并与延迟写入：
- 日志合并：很多应用都有自己的日志模块。避免每条日志都调用write()或fprintf()后跟fflush()。应该实现一个带缓冲的日志系统，积累一定量的日志（如4KB）或定时（如1秒）批量写入一次。这能将大量随机小写变成顺序大写，对eMMC和NAND都极其友好。
- SQLite的写优化：如果使用SQLite，PRAGMA synchronous = NORMAL;或PRAGMA journal_mode = WAL;可以显著提升写入性能。WAL模式将随机写改为顺序写，是数据库场景的必选项。
- 配置fsync()策略：明确区分关键数据和非关键数据。对于可以容忍少量丢失的数据（如缓存、实时上传的传感器临时数据），应避免频繁调用fsync()或fdatasync()。

4. 面向Raw NAND的软件架构设计：拥抱白盒，精细控制

当你决定或需要使用Raw NAND时，软件架构需要从头设计，核心是构建一个高效、可靠的主机侧FTL。

4.1 Linux MTD子系统与UBI/UBIFS：标准化的基石

在Linux中，Raw NAND通过MTD子系统来管理。MTD提供了/dev/mtdX字符设备和/dev/mtdblockX块设备接口。但直接使用mtdblock非常危险，因为它没有坏块处理和磨损均衡。

UBI (Unsorted Block Images)和UBIFS (UBI File System)是Linux社区为Raw NAND提供的“官方”解决方案套件，强烈推荐使用。

UBI：工作在MTD之上。它实现了卷管理、磨损均衡、坏块管理（透明替换）和位翻转处理。你可以将UBI看作一个“闪存管理中间层”，它向上提供多个可靠的、可动态调整大小的逻辑卷（/dev/ubiX_Y）。
UBIFS：专为UBI卷设计的日志文件系统。它去除了传统文件系统中与闪存不兼容的假设（如原地更新），与UBI配合，能提供接近“开箱即用”的可靠性和不错的性能。

使用流程示例：

# 1. 擦除MTD设备（首次使用） flash_erase /dev/mtd0 0 0 # 2. 将MTD设备附加到UBI ubiattach -m 0 -d 0 # 此时会生成 /dev/ubi0 # 3. 在UBI设备上创建卷 ubimkvol /dev/ubi0 -N rootfs -s 100MiB # 生成 /dev/ubi0_0 # 4. 在卷上创建UBIFS文件系统 mkfs.ubifs -r /path/to/rootfs/files -m 2048 -e 126976 -c 1024 -o ubifs.img # 5. 使用ubiupdatevol将镜像写入卷，或直接挂载 mount -t ubifs ubi0:rootfs /mnt/ubifs

关键参数：-e（逻辑擦除块大小，需匹配UBI）和-c（最大逻辑擦除块数）需要根据NAND物理参数和UBI配置仔细计算。

4.2 自研FTL的核心考量：当标准方案不够用时

UBI/UBIFS适用于大多数通用场景。但在极端追求性能、确定性延迟或特殊访问模式的场景下（如高频、固定位置的元数据更新），你可能需要考虑自研或深度定制FTL。这涉及以下核心模块：

地址映射：
- 页级映射 vs 块级映射：页级映射灵活，写性能高，但映射表大（占用RAM）。块级映射表小，但写放大严重。混合映射是折中方案，如FTL（Log-structured FTL）：将数据顺序写入日志区，满后与旧数据块合并。这是现代SSD和eMMC内部FTL的主流思想。
- 映射表缓存：整个映射表无法全放RAM。需要实现LRU等缓存算法，缓存热点数据的映射关系。缓存命中率直接决定随机读性能。
垃圾回收：
- 时机：后台空闲时回收，还是被动触发？后台回收能平滑延迟，但增加功耗。
- 策略：选择哪个块进行回收？贪心算法（选择无效页最多的块）回收效率高，但可能导致某些块磨损过快。成本效益算法会综合考虑无效页比例和磨损程度，是更均衡的选择。
- 写放大控制：垃圾回收本身会产生额外的写入。需要在回收阈值、空间放大、写放大之间取得平衡。通常建议保持闪存有一定比例（如10%-20%）的预留空间（OP, Over-Provisioning），这能极大改善垃圾回收效率和寿命。
磨损均衡：
- 动态磨损均衡：在分配新的空闲块时，优先选择擦除次数少的块。
- 静态磨损均衡：定期将“冷数据”（很少改写的数据）从年轻块迁移到年老块，让所有块的磨损进度趋同。这对于延长存储寿命至关重要。
坏块管理：
- 工厂坏块：在出厂坏块表（BBT）中标记。
- 运行时坏块：在擦除或编程失败时识别，并将其加入运行时坏块表。FTL需要将逻辑地址映射到备用好块上。

一个简化的自研FTL数据写入流程示意：

应用写入逻辑页A。
FTL在日志区找一个空闲物理页P。
将数据写入物理页P。
更新RAM中的映射表：逻辑页A -> 物理页P。
将此次映射关系写入闪存的特定日志区（用于掉电恢复）。
原物理页A‘被标记为无效。
后台垃圾回收线程发现某个块无效页很多，将其中的有效页（如有）搬走，然后擦除该块，将其加入空闲块池。

4.3 性能与寿命的权衡：关键参数调优

使用Raw NAND，你获得了调优的自主权，但也承担了调优的责任。

预留空间：这是最重要的参数之一。更多的OP意味着：
- 更低的写放大（垃圾回收效率高）。
- 更高的性能（特别是持续写入性能）。
- 更长的寿命。
- 但代价是可用容量减少。对于消费级TLC NAND，建议至少15%的OP；对于工业级MLC，可以适当降低，但不应低于10%。
ECC强度与纠错能力：NAND控制器或软件ECC需要配置纠错能力。更强的ECC（如BCH纠40bit/1KB）能应对更恶劣的数据保存条件，但计算开销大、延迟高。需要根据NAND数据手册的推荐值和产品使用环境（温度、数据保留期）来选择。
读写缓存策略：
- 写缓存：启用后，数据先写入RAM缓存即返回成功，再由后台线程刷入闪存。极大提升写入速度，但断电有数据丢失风险。必须配合超级电容等掉电保护方案，或仅用于非关键数据。
- 读缓存：缓存最近读取的数据页。对读密集型应用效果好。

5. 从eMMC迁移到NAND的实战路径与避坑指南

如果你计划在新项目中采用Raw NAND，或从eMMC迁移，以下是一个可行的实战路径。

5.1 硬件选型与驱动适配

NAND选型：
- 接口：SPI NAND（接口简单，引脚少，速度较慢） vs 并行NAND（速度快，引脚多）。根据带宽需求选择。
- 容量与页大小：确定需求容量。注意页大小（Page Size）和块大小（Block Size），这直接影响软件参数配置。
- ECC要求：确认芯片所需的ECC强度，并确保你的SoC的NAND控制器或你选择的软件ECC方案能满足要求。
驱动适配：
- 确保Linux内核包含了对应型号NAND芯片的驱动。可能需要在内核中配置CONFIG_MTD_NAND_XXX。
- 在设备树（Device Tree）中正确描述NAND控制器和芯片信息，包括时序参数。时序参数配置错误是导致数据错误或不稳定的常见原因，务必参考芯片数据手册和SoC参考设计。

5.2 启动引导的挑战：Bootloader如何访问NAND？

这是迁移中最关键的环节之一。eMMC通常有硬件引导分区，而Raw NAND需要Bootloader支持。

SPL + U-Boot：这是主流方案。第一阶段的SPL（Secondary Program Loader）需要内置最精简的NAND驱动，用于从NAND的固定偏移量处加载完整的U-Boot。U-Boot再加载内核。
存储布局：需要在NAND起始部分规划好固定的区域，用于存放SPL、U-Boot环境变量、U-Boot主体、内核和设备树、根文件系统等。通常使用mtdparts参数来定义这个布局。
UBI在Bootloader中的支持：U-Boot需要编译时加入CONFIG_CMD_UBI和CONFIG_CMD_UBIFS支持，才能识别和挂载UBIFS格式的根文件系统。

一个典型的NAND分区布局（在U-Boot中定义）：

mtdparts=nand:1M(SPL),1M(SPL.backup),1M(U-Boot),128K(U-Boot.env),128K(U-Boot.env.backup),-(UBI)

这个布局定义了从NAND起始的1MB给SPL，并留有备份，然后是U-Boot及其环境变量，剩余所有空间给UBI卷。

5.3 系统构建与镜像烧写

构建支持UBIFS的根文件系统：在Buildroot或Yocto等构建系统中，选择ubifs作为根文件系统的输出格式，并正确设置mkfs.ubifs的参数（-m,-e,-c）。
生成复合镜像：需要将SPL、U-Boot、内核、设备树、根文件系统镜像按照预定的布局打包成一个完整的烧写镜像，或者分别烧写到对应偏移量。

烧写工具：不能再用简单的dd命令。需要使用nandwrite工具（来自mtd-utils包）来烧写，它会跳过坏块。

flash_erase /dev/mtd0 0 0 # 全片擦除，谨慎使用！ nandwrite -p /dev/mtd0 u-boot.img nandwrite -p /dev/mtd2 -s 0x200000 uImage # 从偏移2MB处烧写内核

5.4 常见问题与排查

系统无法从NAND启动：
- 检查SPL是否被正确烧写到偏移0处。
- 检查SPL中的NAND驱动初始化代码和时序配置。
- 使用示波器或逻辑分析仪测量NAND的CE、WE、RE等控制信号，确认时序符合数据手册要求。
UBIFS挂载失败，提示“Invalid argument”：
- 最常见原因：mkfs.ubifs或ubinize使用的参数（尤其是逻辑擦除块大小-e）与内核中UBI驱动检测到的物理擦除块大小不匹配。必须保证两者完全一致。物理擦除块大小通常为页大小 * 每块页数，但需要减去用于存储元数据（如OOB）的部分。使用ubinfo命令查看UBI设备信息进行核对。
运行时出现ECC纠错错误或数据损坏：
- 检查硬件连接是否稳定。
- 确认驱动中配置的ECC强度和模式与NAND芯片要求一致。
- 检查电源是否干净、稳定。NAND对电源噪声比较敏感。
- 如果使用了写缓存，考虑是否为意外掉电导致缓存数据丢失。