1. 为什么嵌入式文件系统会盯上 RAID5先给不熟悉存储这块的朋友说下背景。传统印象里嵌入式设备跟 RAID 这种企业级技术八竿子打不着。以前我们做嵌入式存储介质基本就是 SD 卡、eMMC、Nor Flash 轮着用文件系统选个 FAT、ext4 或者 JFFS2 这种带掉电保护的数据可靠性主要靠单盘折腾。但是这几年情况明显变了工业控制、边缘计算网关、车载记录仪、NAS 小主机甚至一些科研采集设备跑的数据量越来越大单块存储介质根本扛不住容量和可靠性两方面的压力。我这次做的事是在一个嵌入式文件系统里加入 RAID5 支持。说直白点就是让跑在 ARM 或者低功耗 x86 平台上的文件系统自己去管理多块硬盘或者 eMMC把数据像 RAID5 那样条带化分布同时分布式地存一份校验信息。任何一块盘挂了文件系统照常工作数据不丢换上新盘还能重建回来。这条能力在 PC 服务器上见怪不怪但在嵌入式环境里落地踩的坑完全不一样。如果你手头也在做类似的事情——比如想把自研的嵌入式存储方案做得更皮实或者在评估文件系统层面直接做冗余的可行性——这篇就聊聊我这次的完整设计思路、实现过程中遇到的坑以及最后实测下来的性能表现。顺带也会聊一个嵌入式场景下避不开的话题RAID5 和 RAID10 到底该怎么选。1.1 什么样的嵌入式场景真的需要 RAID5很多人一听到嵌入式 RAID5第一反应是有必要吗我一开始也这么想后来被实际需求打脸了。拿我们这次的目标场景举例一台边缘计算网关里面要塞 4 块 2.5 寸 SATA SSD跑的是工业现场的实时数据库和历史趋势归档。现场环境是 7x24 小时不间断运行设备放在户外机柜里夏天温度能到 50 度震动、断电、电压波动全都是家常便饭。这种环境下单块 SSD 的故障率并没有想象中那么低而一旦系统盘挂了恢复不了现场工程师得跑一趟现场重新部署成本可能比设备本身还贵。另一个典型场景是车载和轨交记录仪。法规要求黑匣子数据必须完整保留但存储介质本身可能随时遭遇物理冲击。RAID5 能扛单盘故障两块盘同时挂的概率在概率学上已经足够低对于这种场景是性价比最高的选择。还有一类是小型 NAS 和私有云盒子。不少用户把家庭照片、工作文档都存在里面的多块盘上希望容量利用率高一点又能接受一块盘故障不丢数据。RAID5 对这类用户是远比 RAID1 更实用的方案。所以核心判断标准就三条多块独立存储介质、数据需要持续写入不能中断、单盘故障会造成不可接受的数据丢失或业务中断。满足这三条的嵌入式产品都是 RAID5 的合理应用对象。1.2 传统 RAID 实现为什么不适合直接搬过来不少做嵌入式的同事第一反应是RAID 不是现成的吗Linux 内核有 md 模块硬件也有 RAID 卡直接叠上去不就行了说实话在 x86 工控机上这么干确实没毛病但放到嵌入式环境里问题一个接一个硬件 RAID 卡功耗高、体积大、贵。嵌入式主板的 PCB 面积和功耗预算卡得死死的加一块 RAID 卡可能整机功耗直接超标。软件 RAIDLinux md是内核态的独立层位于块设备和文件系统之间。它对嵌入式场景的适配并不友好要么依赖完整 Linux 内核要么你得自己裁剪移植而且 md 层的缓冲区管理、线程调度策略都不是为小内存、低 CPU 主频的嵌入式环境设计的。最重要的是很多嵌入式文件系统并不是 ext4/xfs而是厂商自研的、带日志或掉电保护的专有格式。它们往往直接管理裸设备无法在中间塞一层标准 RAID 驱动。所以这次项目的技术决策很明确不做独立 RAID 层而是把 RAID5 的逻辑直接融入文件系统自身让文件系统成为懂冗余的存储管理者。这样既可以统一管理 IO 调度和掉电恢复又能精准控制内存占用和行为特性是嵌入式环境下更务实的一条路。2. 整体设计文件系统里的 RAID5 到底怎么长出来确定了大方向——在嵌入式文件系统内部实现 RAID5 语义接下来的问题就是怎么设计这个结构才不把文件系统本身搞乱。2.1 文件系统与 RAID 之间的责任边界先理清一层关系。传统架构里文件系统的职责是把数据组织成文件和目录RAID 的职责是把底层多块盘拼成一个可靠的块设备。两者是上下层关系互相不关心对方内部逻辑。把 RAID5 融进文件系统之后边界其实变了。文件系统不只是文件管理器它还要充当条带化调度器和校验计算器。但有一点必须保持清楚文件系统的语义不能乱。应用层读写文件的行为跟它是不是 RAID5 无关打开文件、写入数据、读取数据这些接口必须和以前完全一致。我的设计是引入一层虚拟卷抽象。文件系统内部多了一个虚拟卷的概念每个虚拟卷背后绑定一组物理盘一般 3 到 8 块虚拟卷内有独立的块分配器负责把文件的逻辑块映射到物理盘的物理块上这个映射关系就携带 RAID5 的条带和校验策略。文件系统原来的目录树、inode 管理、日志系统完全构建在虚拟卷之上感知不到底层盘的变化。2.2 条带化布局与分块大小怎么定RAID5 最核心的是条带化布局。简单说就是把连续的数据切成一格一格的块轮流写到不同盘上。设磁盘数量为 N每次写 N-1 个数据块剩下 1 个写校验块。校验块的位置在每条条带内部做轮转避免某一块盘总是承担校验写入导致寿命不均。分块chunk/stripe unit大小是我最先要定的参数。嵌入式设备常见值有 64KB、128KB、256KB。选小了对小文件友好但校验计算频率高、IO 次数多选大了顺序大文件吞吐好但小文件随机写放大明显而且单块盘故障后重建时需要读的跨度大。我这次均衡下来选了 128KB兼顾了顺序读写和小文件性能。如果读者做的产品是高清视频写入为主可以调大到 256KB如果是 IoT 设备大量小日志64KB 更合适。这个参数在虚拟卷创建时固定运行期改不了所以前期测试要充分。2.3 校验块的分布算法校验块的轮转公式不复杂。设条带内块序号从 0 到 N-1校验块在条带号 p 中的位置是 (N-1 - (p % N))。数据块的位置就是除了这个位置以外的其它 N-1 个槽位。这样每个条带的校验块分散到不同盘上每块盘承担的校验写压力宏观上一样。用 N4 的磁盘组举例条带 0 的校验在第 3 块盘条带 1 的校验在第 2 块盘条带 2 的校验在第 1 块盘条带 3 的校验在第 0 块盘条带 4 又回到第 3 块。整个组里数据量跟校验量的比例始终是 3:1可用容量是总容量的 75%。2.4 关键模块块分配器、日志、IO 调度器整个实现分为三个核心模块块分配器负责选盘和选偏移。每次要写一个逻辑块分配器会查当前条带游标决定去哪块盘、写哪个偏移同时记住该条带内的校验盘位置。这个逻辑要尽量快不能每条 IO 都做复杂查表所以我把条带映射表放在内存里用位图加速。日志子系统要做扩展因为 RAID5 的写前日志比普通文件系统复杂。如果中途掉电会存在部分条带已经写了新数据但校验没更新的情况。这时候必须能检测出来并回滚或重放。我的方案是给每个条带加一个世代号generation写数据前先把条带世代号记入日志完成写入后再提交。恢复时发现某个条带的世代号不连续就认为该条带处于不一致状态需要重建恢复。IO 调度器负责把逻辑 IO 合并成物理 IO。RAID5 最大的麻烦是读-改-写序列。应用只写了 4KB但 RAID5 需要读旧数据、读旧校验、计算新校验、写新数据、写新校验一个逻辑写变成五次物理访问。调度器会把同一磁道的写请求合并等条带凑齐了再一起写尽量把读-改-写变成整条带写。3. 实操落地从奇偶校验算法到掉电安全3.1 奇偶校验计算别小看 XORRAID5 校验算法本质上就是异或XOR运算。新校验 旧数据 XOR 新数据 XOR 旧校验。这个等式在任何一个数据块更新时都成立。嵌入式 CPU 算 XOR 很便宜ARM Cortex-A 系列一条指令就能处理 64 位数据但数据量大时不能纯靠 CPU 硬算。我做了两层优化第一层如果写入的数据刚好覆盖整个条带所有数据块都是新的就不需要读旧数据旧校验直接对 N-1 个数据块做 XOR 得到新校验一次写满整个条带。这是 RAID5 的最高效路径。第二层如果只写了部分块适合走读-改-写只需要读被修改块和对应校验块算出新校验。这个流程涉及两次读、两次写加上计算开销确实不小。实测下来Cortex-A53 1.5GHz 主频上1MB 数据的 XOR 计算大概耗时 3 到 5 毫秒相对磁盘 IO 时间十几毫秒不算瓶颈。但要注意主控芯片如果还要跑业务CPU 占用会明显涨。所以我做了个简单的校验计算线程池利用多核 CPU 分散计算负载避免 IO 路径被校验计算堵住。3.2 写路径的条带组装逻辑写路径是实现中最容易出 bug 的地方。核心逻辑是条带缓存 延迟提交应用写入数据文件系统按逻辑块地址定位到某个条带。数据先写入条带缓存strip cache缓存里记录哪些块是脏的。当脏块数量达到条带满员条件或者达到刷新超时阈值就触发一次条带提交。提交前检查脏块数满 N-1 块直接全部 XOR 算校验一次写完。不满 N-1 块读旧数据、读旧校验走读改写流程。校验计算完成后把数据块和校验块按目标盘分别下发。有个细节必须提醒条带缓存不能无限大。内存紧张的嵌入式设备条带缓存一般设 4 到 8 个条带就够了超过阈值强制刷出。缓存淘汰策略我用的是最久未提交优先避免某个条带长期占用缓存。3.3 掉电一致性重建流程与坏盘标记嵌入式环境最怕掉电。RAID5 如果掉电时条带处于半写状态重启后数据可能是旧的也可能是新的校验跟数据对不上。我的方案是前面提过的世代号 日志组合。具体流程每个条带元数据里存一个 32 位世代号。写条带前先把目标世代号写入日志区日志区放在所有盘之外可以是一块小容量的 SPI NOR Flash 或磁盘预留区。写完数据块和校验块后再把条带元数据里的世代号更新。重启扫描日志如果发现某个条带的日志世代号比元数据里的新说明写操作没完成就把这个条带标记为待重建。待重建条带的数据恢复有两种做法。如果损坏区域恰好是数据块可以直接用其它数据块和校验块 XOR 反解如果损坏的是校验块直接重新计算追平即可。整个恢复过程也就是 RAID5 的重建流程。3.4 成员盘状态管理文件系统跑起来之后需要实时监控每块盘的健康状态。嵌入式环境下没有企业级硬盘的 SMART 通道那么完善我就用IO 错误计数 响应超时双指标来判定盘是否失效。IO 错误计数连续超过阈值比如 10 次或者某块盘响应超时达到 30 秒就把这张盘标记为失效。失效盘上的数据立即从条带中剥离系统进入降级模式所有读请求通过其余盘 XOR 计算恢复所有写请求跳过这块盘继续写同时把校验关系临时调整。这里有个坑降级模式下如果又有一块盘失效RAID5 就真的救不回来了。所以失效盘一定要立刻报警建议在系统里留一个 GPIO 或网络告警出口。4. RAID5 与 RAID10 的嵌入式选型对比既然是做嵌入式文件系统的 RAID5就绕不开RAID5 还是 RAID10这个经典选择题。我直接把我这次的实测对比数据放出来结合嵌入式场景的约束来聊。4.1 容量利用率与成本对比先看最直观的容量账。设总共有 N 块盘单盘容量 CRAID5 可用容量 (N-1) * C。4 块 1TB 盘的可用容量是 3TB利用率 75%。RAID10 可用容量 (N/2) * C。4 块 1TB 盘的可用容量是 2TB利用率 50%。嵌入式产品做硬件选型时每块盘都是实打实的成本。同样 4 盘位RAID5 能多出 1TB 可用空间这在产品定价和竞争力上是很明显的优势。如果产品经理告诉你预算只能上 4 块盘可用容量不能低于 3TB那基本没得选只能 RAID5。4.2 写性能与读性能差异对比条件4 块 SATA SSD 组 RAID5条带块 128KBRAID5 带延迟提交RAID10 组用同样的盘走镜像 条带。测试工具用 fio队列深度 32块大小分布覆盖 4KB 到 1MB。顺序读性能两者几乎一致都能到单盘读速率的 N 倍受总线瓶颈限制RAID5 略高一点因为数据块分布更均匀。顺序写性能RAID5 因为校验计算和条带提交会损失一部分带宽。在 1MB 大块顺序写场景RAID5 大概是 RAID10 的 85% 到 90%差距能接受。随机写 4KB 场景差距就拉开了。RAID10 的写惩罚是 2写镜像两份RAID5 的写惩罚是 4读旧数据、读旧校验、写新数据、写新校验。实测下来RAID5 的 4KB 随机写 IOPS 只有 RAID10 的 50% 左右。如果业务里有大量小随机写RAID5 会很难看。嵌入式设备很多都是日志类、采集类顺序写为主这个差距可以接受。但如果你的应用是数据库这类随机写密集场景RAID10 显然更稳。4.3 故障恢复与重建风险这是我最想强调的一个点。RAID5 单盘故障后进入降级模式读性能会明显下降因为每次读都要做 XOR 反解。而且重建过程需要读所有剩余盘的全部数据重建时间跟盘容量和 IO 速度直接相关。举个例子4 块 1TB 的盘重建大概需要 6 到 10 个小时取决于接口速度和 CPU 计算能力。这期间如果再来一块盘故障数据就永久丢失了。RAID10 的重建就快得多只需要从镜像盘完整拷贝数据不涉及 XOR 计算。所以嵌入式长期无人值守的场景如果只有 3 块盘我用 RAID5 会有顾虑如果有 4 块以上盘RAID5 的经济性优势就压过了重建风险可以接受。4.4 嵌入式专项内存、CPU、功耗RAID5 需要条带缓存需要校验计算线程掉电恢复时需要重建这些都会增加内存和 CPU 开销。我实测在 512MB 内存、双核 A53 的平台上RAID5 模块运行稳定态占用内存约 80MB其中条带缓存 64MB元数据 16MB校验计算会让 CPU 占用增加 10%-15%。RAID10 的内存开销就小很多只需要做镜像写几乎不占额外 CPU。如果嵌入式设备本身内存很紧比如 256MB 的旧平台RAID10 可能更现实。最终我这次的结论很明确嵌入式场景盘位 4 个以上、写模式以顺序为主、容量敏感的产品选 RAID5盘位 2 个、随机写敏感、内存紧张的产品选 RAID10。两者不是替代关系是不同场景下的不同正确答案。5. 性能调优与实测数据5.1 关键参数调节条带缓存大小与刷新阈值条带缓存大小直接决定了写聚合效果。缓存太小条带凑不齐就强制刷校验计算效率低缓存太大内存吃紧还会让掉电丢数据的风险窗口变大。我调试了三个典型值64MB、128MB、256MB测试写性能如下表缓存大小顺序写 1MBMB/s随机写 4KBIOPS峰值内存占用64MB408312096MB128MB4523280160MB256MB4613310288MB128MB 到 256MB 的性能提升已经很小但内存翻倍。我最后用 128MB对 512MB 内存平台来说是合理平衡。刷新阈值我设为两种模式。默认条带满员立即刷新追求最低延迟再提供定时器模式比如每 100ms 刷新一次适合需要稳定写入节奏的流媒体场景。定时器模式会让平均延迟略高但抖动小。5.2 fio 基准测试与结果解读用 fio 走一组标准流程建议读者复现时也按这个套路来方便横向对比顺序读 1MB队列深度 32顺序写 1MB队列深度 32随机读 4KB队列深度 32随机写 4KB队列深度 32实测 4 盘 RAID5 结果测试项数值顺序读823 MB/s顺序写452 MB/s随机读 4KB18,400 IOPS随机写 4KB3,280 IOPS顺序读能到 823 MB/s是因为 4 块盘同时读接口速率叠加后接近 SATA 控制器极限。随机读 IOPS 比单盘高不少因为读请求分散在不同盘上并行处理。随机写 IOPS 是最弱的一环前面解释过原因这就是 RAID5 的物理天花板只能靠缓存优化尽量补。5.3 降级模式下的性能变化模拟一块盘拔出系统进入降级模式后我再跑同一组 fio测试项正常模式降级模式变化顺序读823 MB/s465 MB/s-43%顺序写452 MB/s398 MB/s-12%随机读 4KB18,400 IOPS9,700 IOPS-47%随机写 4KB3,280 IOPS3,040 IOPS-7%降级模式下读性能几乎腰斩是因为每次读幸存盘数据时都需要额外读其它盘数据并用 XOR 反解。写性能下降不多因为写仍是把数据写到幸存盘只需调整校验策略。这个数据能直观告诉你在单盘失效后系统的真实表现做产品设计时务必要提前想好降级模式下的业务降载策略。6. 常见问题与排查技巧实录6.1 条带不一致告警但盘没坏这是最容易误判的情况。系统启动扫描时发现某个条带的世代号不一致但所有盘都能正常读写。多半原因是上次掉电时刚好有日志没提交完。处理方式很简单把该条带标记为待重建触发一次恢复一般读取其它盘重新算出数据就能对齐。切忌直接把盘标记失效导致不必要的全盘重建。排查技巧日志里如果只看到零星几个条带号报错大概率是掉电残留如果大量条带报错且集中在某一块盘那就要怀疑那块盘有坏道了。6.2 随机写性能远低于预期如果随机写 IOPS 连理论值一半都不到通常是条带缓存太小或者刷新阈值太激进。我调试时遇到过把刷新阈值设成 10ms结果每个小写入都触发一次读-改-写IOPS 直线下降。调成条带满员刷新后性能立刻回到正常区间。还有一个隐蔽坑如果文件系统本身开启了同步写每次 write 都要等落盘RAID5 的条带聚合会被完全打碎。嵌入式应用如果有同步写需求建议走日志落盘机制而不是让每一个小 IO 都穿透到 RAID5 层。6.3 拔掉一块盘后系统无法启动这是典型的引导工程问题。文件系统里有 RAID5 虚拟卷但引导加载程序bootloader不认这个卷它企图从第一块盘直接引导内核结果盘失效了就起不来。解决办法是单独划分一个引导分区用标准 ext4 或 fat 格式存储内核和 bootloaderRAID5 只承载业务数据。引导分区也可以做成两盘互备的小镜像但没必要加入 RAID5。这个经验我们是一次生产事故换来的提出来希望读者少踩一次坑。6.4 重建过程中 IO 性能波动剧烈RAID5 重建需要大量读幸存盘、计算校验、写新盘跟正常业务 IO 抢带宽和 CPU。如果重建优先级太高业务会卡死太低重建拖太久增加二次故障风险。我建议把重建 IO 的优先级固定成业务不到 60% 负载时才允许跑。实现上就在 IO 调度器里加一个动态带宽控制。实测效果是重建吞吐降到满载的 70%但业务侧基本无感。7. 可扩展方向这次项目做完后续演进我留了几个方向。一是 RAID6。在 RAID5 基础上多一个校验块可以同时容忍两块盘故障。代价是写惩罚进一步增加到 6校验计算复杂度也翻倍。对于数据价值特别高的嵌入式场景值得做。二是把冗余策略做成可配置。一个存储系统同时支持 RAID0、RAID5、RAID10让用户在管理界面里按需选择。目前架构上虚拟卷已经是独立的实现多个策略并存不会伤筋动骨。三是引入快照和远程复制。既然文件系统里已经有条带级元数据做快照可以基于条带级别做 COW写时复制对嵌入式备份场景很有价值。最后再分享一个我在实际测试中养成的习惯每改一次条带逻辑或校验算法一定要做一次完整的掉电注入测试。我这边用一个继电器控制板随机在写入过程中切断整机电源跑 200 轮确认每次都能恢复且数据一致。嵌入式存储的可靠性不是靠代码写出来的是靠这种反复折腾验证出来的。