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是极其困难的因此我们需要在软件栈中引入FTLFlash Translation Layer和MTDMemory Technology Device子系统。FTL负责将块设备的逻辑地址映射到NAND的物理地址并处理坏块管理、磨损均衡、垃圾回收等。MTD则为Linux内核提供了一个访问原始闪存设备的统一抽象层。从eMMC切换到Raw NAND意味着我们将FTL从芯片内部搬到了主机侧从“黑盒”变成了“白盒”。这带来了巨大的挑战但也开启了深度优化的可能性。3. 针对eMMC的软件优化策略在黑盒外做文章当你暂时无法更换硬件或者产品已经定型使用eMMC时以下软件策略可以帮助你显著提升存储性能。3.1 文件系统选型与调优第一道性能闸门文件系统是应用程序与块设备之间的桥梁其设计对性能影响巨大。Ext4 vs. F2FS这是最经典的抉择。Ext4是为磁盘设计的日志文件系统日志机制Journaling在意外断电时能保证数据一致性但会带来额外的写操作数据可能被写入两次。对于eMMC这加剧了写入放大和磨损。F2FSFlash-Friendly File System则是专为NAND类存储设计的。它采用日志结构Log-structured写入更连续能减少垃圾回收压力并具有更好的碎片整理策略。在我们的测试中对于小文件随机写密集型场景F2FS的性能相比Ext4有30%-200%的提升。如果你的应用写操作多特别是随机小文件写F2FS是首选。注意F2FS在空间接近写满时性能下降可能比Ext4更剧烈需要合理规划分区使用率建议预留20%以上空间。关键挂载参数noatime/relatime默认情况下每次读取文件都会更新其访问时间戳atime这意味着一次读操作会触发一次写操作。noatime完全禁止此更新relatime仅在访问时间早于修改时间或状态改变时间时才更新。务必在挂载时加上noatime这对减少无用写入、提升读性能效果立竿见影。dataordered/datawriteback这是Ext4的日志模式。ordered默认只对元数据记日志保证数据在元数据提交前已落盘安全性高。writeback也对元数据记日志但不保证数据写入顺序性能更高但断电可能丢失部分最新数据。在允许一定数据丢失风险的场景如临时文件、缓存可考虑writeback。discard在线TRIM。让文件系统在删除文件时主动通知eMMC哪些块可回收。但不建议在eMMC上使用因为TRIM命令可能引发芯片内部耗时的垃圾回收操作导致命令延迟激增。更好的做法是定期如每周通过fstrim命令离线执行。示例优化的 /etc/fstab 条目# 对于Ext4根文件系统 /dev/mmcblk0p2 / ext4 defaults,noatime,errorsremount-ro 0 1 # 对于F2FS数据分区 /dev/mmcblk0p3 /data f2fs defaults,noatime 0 23.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,size100M 0 0 tmpfs /var/run tmpfs defaults,noatime,size20M 0 0合并与延迟写入日志合并很多应用都有自己的日志模块。避免每条日志都调用write()或fprintf()后跟fflush()。应该实现一个带缓冲的日志系统积累一定量的日志如4KB或定时如1秒批量写入一次。这能将大量随机小写变成顺序大写对eMMC和NAND都极其友好。SQLite的写优化如果使用SQLitePRAGMA 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。块级映射表小但写放大严重。混合映射是折中方案如FTLLog-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这是主流方案。第一阶段的SPLSecondary 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中定义mtdpartsnand: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对电源噪声比较敏感。如果使用了写缓存考虑是否为意外掉电导致缓存数据丢失。从eMMC到NAND的转变是从一个“舒适区”走向“深水区”的过程。它要求开发者从应用层深入到文件系统、块层、甚至闪存管理层的每一个细节。这种深入带来的不仅是挑战更是对系统行为前所未有的掌控力。优化永无止境每一次对延迟的削减、对寿命的延长都源于对这些细节的深刻理解和精心设计。