1、Rootfs可靠性概述

Rootfs，全称是Root Filesystem，根文件系统。说白了，它就是嵌入式系统启动后挂载的第一个文件系统。你想想看，内核启动完成后，总得有个地方去加载init进程、读取配置文件、加载驱动模块吧？这个「地方」就是Rootfs。

我习惯把Rootfs比作一栋房子的地基。房子盖得再漂亮，地基不稳也是白搭。Rootfs里装着系统运行所需的一切：/bin里的基础命令、/etc下的配置文件、/lib中的动态库，还有/dev的设备节点。没有它，系统就是个空壳子。

核心要点：Rootfs ≠ 根分区。Rootfs是一个文件系统实例，而根分区是存储介质上的一个分区。两者经常被混用，但在可靠性设计时必须区分清楚。

在实际项目中，Rootfs通常以这些形式存在：

这个问题我太有发言权了。做嵌入式十年，至少遇到过七八次Rootfs损坏导致设备变砖的故障。原因其实不复杂，我归纳为三类：

这是最常见的杀手。嵌入式设备不像服务器有UPS，说断电就断电。如果正在写文件系统时突然掉电，文件系统元数据可能不一致。我有个项目，设备在野外部署，一年内因为雷雨天气断电导致Rootfs损坏的案例就有十几起。

Flash存储有擦写寿命限制。NAND Flash的P/E Cycle一般在几千到几万次。如果频繁写入日志或临时文件，坏块会逐渐增多。当坏块管理机制失效时，Rootfs就可能出现不可修复的损坏。

注意：我曾经遇到一个案例，某款廉价eMMC芯片在高温环境下（65℃+）连续写入3个月后，出现了大量不可纠正的ECC错误。Rootfs直接挂掉，设备彻底失联。

嗯，这里要坦诚地说，很多时候是我们自己挖的坑。比如：

搞清楚了Rootfs是什么、为什么会坏，那我们的设计目标就很明确了。我个人认为，Rootfs可靠性设计要围绕三个核心目标展开：

这三个目标是有优先级的。防损坏排第一，因为不出事永远是最好的。能检测排第二，很多设备损坏了还在「带病运行」，直到彻底死机才发现。可恢复排最后，但它是兜底方案，必须要有。

我的经验：在工业级产品中，我建议把「防损坏」做到90分，「能检测」做到80分，「可恢复」做到60分就够了。因为恢复机制本身也会引入复杂度，复杂度是可靠性的敌人。

下面这张图是我自己总结的Rootfs可靠性设计框架，你可以看看整体脉络：

这张图把三个核心目标以及对应的实现手段都串起来了。你仔细看，每个目标下面都有三条具体的实现路径。在后续的章节里，我会逐一展开讲这些手段的具体实现方法。

最后说一句，Rootfs可靠性不是某一个功能点能解决的，它是一个系统工程。从文件系统选型、分区布局、升级策略到异常处理，每个环节都要考虑。我见过太多项目，只做了双备份就觉得万事大吉，结果切换逻辑有bug，照样变砖。

嗯，这一章先到这里。记住这三个核心目标，后面的内容都是围绕它们展开的。