在工控行业里摸爬滚打这几年接触最多的就是各种单板跑 Linux 的设备工业 HMI、边缘采集网关、运动控制板还有一堆叫不上名字的专用终端。这类设备和开发板最大的区别在于它是要 7x24 小时在现场跑的而且维护人员的水平参差不齐现场环境更是恶劣——突然断电、灰尘、震动、高温都是家常便饭。所以这里跑 Linux 不能照搬服务器那一套也不能照着树莓派的做法来存储配置、系统升级、故障恢复这套东西必须从设计之初就严丝合缝地规划好。这篇主要讲三个核心问题存储怎么分区才扛得住工控环境、系统怎么升级才安全可回滚、以及如何用 OverlayFS 实现一个真正好用的“恢复出厂”功能。这套组合拳我在多个项目里验证过从瑞芯微到全志再到几款国产 x86 板子都试过逻辑是通用的具体参数我会尽量给全。1. 工控单板 Linux 的整体设计与存储思路1.1 工控单板到底特殊在哪里工控单板和我们平时玩的树莓派、香橙派看着像实际上设计逻辑完全不一样。开发板强调折腾工控板强调稳定。客户现场装上去的设备少则三年多则五年八年不关机系统崩溃一次可能就是产线停线、数据丢失代价非常大。所以在做这类系统时第一原则就是默认你已经遇到了最坏的情况。比如客户可能会在系统正在写日志的时候直接断电可能会拿着 U 盘拷数据把系统文件误删可能会反复升级失败然后怪你产品不行。我们要做的不是祈祷这些事不发生而是让系统在遭遇这些事之后还能自己恢复或者用一个简单的操作就能恢复。另一个工控场景的特殊之处是网络环境。很多工厂的内网是隔离的设备根本访问不了外网。这意味着系统更新不能依赖在线软件源必须走离线升级包。也正因如此我们的存储规划里通常会为系统备份、升级包缓存预留一部分空间。1.2 存储介质选型eMMC 是绝对主流工控单板的存储介质就那么几类我把这几年的选型经验整理出来存储介质优点缺点工控场景建议eMMC内置坏块管理、抗震动、寿命较好、价格适中容量相对固定、磨损仍存在首选系统盘和数据盘都合适SD/TF 卡容量大、更换方便容易被弹出、接触不良、寿命参差不齐千万别当作系统盘最多做扩展存储SATA/NVMe SSD容量大、速度快成本高、体积大、功耗高数据量大的设备可选但要注意掉电保护SPI NOR Flash寿命长、启动快、可靠性极高容量太小通常几 MB 到几十 MB只放 bootloader 和硬件参数NAND Flash成本低、容量适中需要软件做坏块管理、有 OOB 区问题老平台还在用新设计不如直接用 eMMC从可靠性角度来说eMMC 赢在封装一体化和内置 FTL闪存转换层。它里面有独立的控制器管理逻辑块到物理块的映射、磨损均衡、坏块替换这些对上层应用是透明的。你写数据时不用关心底层擦写次数只要关注自己软件的写入量是否合理。我踩过的坑是 SD 卡做系统盘。某项目为了省成本用了工业级 SD 卡结果客户现场设备震动大SD 卡偶尔接触不良系统直接 I/O 错误崩溃而且恢复起来很麻烦。后来换 eMMC 方案再没出过这个问题。1.3 存储可靠性是恢复出厂的基石很多人在做“恢复出厂”功能时脑子里想到的是备份一个系统镜像出问题再用镜像恢复。这个思路没错但如果在存储规划阶段没做好后面全是麻烦。最基本的逻辑是恢复出厂要恢复到一个“干净”的状态那么这个干净状态就必须是物理隔离的、不被日常运行污染的。如果你把根文件系统和用户数据混在一个可写分区里所谓恢复出厂就只能靠完整重刷整个分区——这样既慢又容易出问题而且会把不该清的用户数据也抹掉。所以在我的设计里系统恢复的关键不是一个“救火”脚本而是存储布局本身系统区保持只读可写数据集中在独立的 data 分区运行时改动放到 OverlayFS 的上层。这样恢复出厂只需要清理 OverlayFS 的上层目录秒级完成而且用户数据可以保留。2. 存储配置分区规划与读写控制2.1 典型工控单板分区规划以一块 8GB eMMC、跑 Debian/Ubuntu 系统的工控单板为例我习惯的分区方案是这样的分区大小文件系统挂载点读写属性说明/dev/mmcblk0p1256MBext4/bootro内核、设备树、启动参数/dev/mmcblk0p22GBext4/ (rootfs)ro可通过 overlay 变可写系统根文件系统/dev/mmcblk0p3512MBext4/datarw应用配置、用户数据、日志缓存/dev/mmcblk0p4512MBext4/overlayrwOverlayFS 的 upper 与 work 目录/dev/mmcblk0p5512MBext4/mnt/backuprw出厂备份与升级包暂存区剩余空间视 eMMC 容量ext4/home 或 /var/lib/dockerrw业务数据扩展区这个分区表看着简单但每个分区的读写属性都是刻意设计的。rootfs 默认只读挂载所有系统文件不会被篡改/data 保存需要持久化的用户数据即使恢复出厂也能保留/overlay 专门给 OverlayFS 当可写层是“恢复出厂”功能的核心。分区空间虽然不大但对工控系统来说完全够用——系统目录几百 MB 就装完了。容量较大的 eMMC16GB/32GB可以在后面加一个大分区给业务数据或者拆成多个逻辑分区给 Docker 用。2.2 让根文件系统“真的只读”把 rootfs 挂载为只读这件事说易行难很多人改了 /etc/fstab 后发现系统起不来或者一堆服务报错。原因在于很多应用和系统服务默认就要往 / 里面写东西——/var/log 要写日志、/run 要写运行时文件、/tmp 要放临时文件、/etc 有时要改配置。我用的方案是“rootfs 只读 关键路径 tmpfs 覆盖”。具体做法# /etc/fstab 关键部分 /dev/mmcblk0p2 / ext4 defaults,noatime,ro 0 1 tmpfs /tmp tmpfs defaults,size64M,mode1777 0 0 tmpfs /var/log tmpfs defaults,size32M,mode0755 0 0 tmpfs /var/tmp tmpfs defaults,size16M,mode1777 0 0然后把 /var/log 里的系统日志通过 rsyslog 配置写到 /data/logs 或者一个独立的数据分区。systemd-journald 也要改 Storage 配置避免它往 /var/log/journal 写东西。另外/etc 下面有些运行时配置需要可写比如 DHCP 申请的 DNS、某些软件的许可证文件。我一个项目里的处理是把所有“运行时要动态写入 /etc 的文件”统一重定向到 /data/etc 下用完再通过 bind mount 回填mkdir -p /data/etc mount --bind /data/etc /etc/network这样 rootfs 的只读不会被打破而业务上需要的“可写”又都能满足。第一次调的时候挺折腾但调好之后省心太多了。2.3 日志轮转与写入量控制工控设备最怕的不是系统文件被改而是闪存被写坏。eMMC 虽然有磨损均衡但也是有寿命的一个严重的日志死循环可以在几个月内干掉一块好好的 eMMC。处理思路就两条少写、限速。少写是指日志和临时文件不要落在持久化介质上用 tmpfs 顶住限速是必须写持久化的日志时用 logrotate 按大小和份数轮转避免无限增长。我常用的配置/var/log/app/*.log { daily rotate 14 maxsize 64M compress copytruncate missingok }还有一个容易忽略的地方数据库和缓存。如果设备上有 SQLite 或者一些 KV 存储一定要把库文件放到 /data 而不是 /root 或 /var/lib。SQLite 的 WAL 模式会频繁写盘对闪存寿命很不友好如果业务允许尽量用内存库定时刷盘或者调大 checkpoint 间隔。2.4 为什么强调物理分区隔离我这里说的“物理分区隔离”是指 rootfs、overlay 上层、用户数据必须放在三个独立分区而不是同一个分区下的三个目录。原因在于OverlayFS 的 upper 目录如果和 lower 的底层分区是同一个文件系统且该文件系统是可写的那么一旦 rootfs 里有文件被修改底层的 lower 就被污染了最终 OverlayFS 的合并视图会非常混乱。实际做过实验rootfs 和 overlay 在同一分区时如果系统服务不小心往 / 下写了一个和 lower 中同名文件OverlayFS 的 copy-up 逻辑会被绕过底层文件直接被改掉。等你想做恢复出厂、清空 upper 时发现底层文件也变了恢复到的是一个不干净的状态。分区隔离之后这个问题彻底消失。upper 的改动永远只落在自己的分区里和 lower 底层互不干扰。3. 系统升级实操离线升级与双分区切换3.1 为什么工控升级必须走离线包在线升级方便但工控现场真的不适合。工业网络往往有严格的隔离策略设备可能连网关都不通即便能联网也不能保证目标设备能稳定地从服务器拉取大量数据。更实际的一点是工控系统的升级行为需要可审计、可重复、可回滚。我接触过的客户升级都要求有明确的版本号、升级记录、操作日志这些在线升级很难给到。所以我一般采用离线升级包 双分区切换的方案。升级包是一个带校验信息的 tar.gz或者更规范一点是一个自解压的升级脚本集合里面包含完整的文件系统镜像、内核、设备树、升级脚本和校验文件。3.2 双分区A/B升级的原理与优势双分区升级的思路很直白把 rootfs 分成 A、B 两份当前运行的是 A升级时往 B 里写写完验证无误后把启动标志切到 B重启后 U-Boot 从 B 启动。如果 B 启动失败U-Boot 检测到启动次数异常自动回滚到 A。这个方案的优点在于升级过程对当前运行的系统完全无影响即使升级写到一半断电A 系统依然完好即使 B 系统起来后有问题也能自动回滚不会变砖。对工控设备来说这个“保底”太重要了。具体到分区规划就是在前面那个表的基础上再加一个 rootfs_b分区大小挂载点说明/dev/mmcblk0p22GB/ (rootfs_a)当前运行的系统/dev/mmcblk0p32GB/mnt/rootfs_b备用系统升级目标启动槽位的记录我放在 /boot 分区下一个文件里U-Boot 通过读取这个文件决定从哪个 rootfs 加载。也可以把启动槽位存在 U-Boot 环境变量或 misc 分区看你的引导链怎么设计方便。3.3 离线升级脚本的设计与实现升级脚本是整个升级流程的核心。我的升级包结构长这样upgrade_package/ ├── VERSION ├── checksums.md5 ├── rootfs_b.tar.gz ├── kernel.itb ├── u-boot.bin └── upgrade.shupgrade.sh 的关键逻辑如下简化版#!/bin/bash set -euo pipefail INACTIVE_ROOT/dev/mmcblk0p3 MNT_ROOT/mnt/upgrade_root BOOT_DIR/boot echo Upgrade script start # 1. 校验升级包完整性 md5sum -c checksums.md5 if [ $? -ne 0 ]; then echo Checksum failed. Abort. exit 1 fi # 2. 检查备用分区是否可写先卸载再挂载 umount $MNT_ROOT 2/dev/null || true mount $INACTIVE_ROOT $MNT_ROOT # 3. 清空目标分区 rm -rf $MNT_ROOT/* # 4. 解压文件系统 tar xzf rootfs_b.tar.gz -C $MNT_ROOT sync # 5. 写入内核/设备树到 boot 分区 cp kernel.itb $BOOT_DIR/kernel_b.itb sync # 6. 写入启动槽位标记 echo B $BOOT_DIR/active_slot sync # 7. 卸载并完成 umount $MNT_ROOT echo Upgrade done, reboot to activate 这里最关键的一步是第 6 步——只有系统文件全部写完后才修改启动槽位标记。如果第 5 步或者第 6 步之前断电重启系统还按旧槽位启动升级失败但原系统不损坏如果第 6 步之后断电B 分区已经有了完整系统启动后进入新版本本身也没问题。这就是“先写数据、后写标志”的断电保护策略。3.4 U-Boot 侧的双分区引导与自动回滚U-Boot 侧的引导逻辑要配合启动槽位标记工作。以最简单的方案为例U-Boot 环境变量 bootcmd 中做一次检测if test -f ${bootpart}/active_slot; then slot$(cat ${bootpart}/active_slot) else slotA fi if test ${slot} B; then setenv rootspec root/dev/mmcblk0p3 rootfstypeext4 else setenv rootspec root/dev/mmcblk0p2 rootfstypeext4 fi自动回滚的原理也很简单在 B 系统正常启动且健康检查通过后在 Linux 里把一个“标记文件”写到 boot 分区表示这次启动是成功启动U-Boot 每次启动时检查如果指定槽位没有成功标记且启动次数达到阈值就回退到另一个槽位# 在系统启动脚本中执行 if [ -f /boot/active_slot ]; then slot$(cat /boot/active_slot) touch /boot/${slot}_boot_ok # 清理失败计数 setenv -f bootcount 0 fiU-Boot 中对应逻辑if test -f ${bootpart}/B_boot_ok; then setenv slot B elif test ${bootcount} -ge 2; then echo Boot B failed, rollback to A setenv slot A setenv bootcount 0 fi这套机制我在实际项目中跑了一年多客户那边也有过几次升级失败的情况基本都是 U-Boot 自动回滚到旧版本解决的运维同学反馈“体验还可以重启一下就好了”。3.5 简化版方案单分区 备份包恢复如果你的 eMMC 空间紧张或者产品定位里不太需要反复升级也可以用简化方案rootfs 只保留一份但在 /backup 分区保存一个出厂时的 rootfs 镜像。升级时对当前 rootfs 做覆盖失败时从备份包恢复。这个方案的缺点是升级过程会打断业务而且覆盖写 rootfs 时如果断电会变砖要么靠备份恢复要么靠刷机工具救砖可靠性明显低于双分区。所以我的建议是只要能承担几百 MB 的空间成本优先上双分区空间实在紧张的再考虑简化版。4. OverlayFS 恢复出厂原理与实操4.1 OverlayFS 到底是个什么东西OverlayFS 是 Linux 内核自带的一种联合文件系统作用是“把两个目录叠在一起看”。这里用一个生活化类比想象你有一张写满字的纸lowerdir只读底层又拿来一张半透明的纸upperdir可写上层盖在上面。你透过上面那张纸看到的是两张纸叠加后的效果下面的字能看见上面的字也能看见。如果我在上面的纸上写字不会影响到下面那张纸如果我把上面那张纸揭开丢掉换一张新的半透明纸盖上去看到的又变回最初那一层的内容——这不就是恢复出厂吗。在内核层面OverlayFS 有四个关键目录目录作用生命周期lowerdir只读底层一般是根文件系统永远不变upperdir可写上层所有修改都在这里恢复出厂时清空workdirOverlayFS 元数据工作目录恢复出厂时清空merged叠加视图应用实际读取/写入的地方动态生成当应用修改一个 lowerdir 里的文件时OverlayFS 会先把该文件“复制”到 upperdir这叫 copy-up再在 upperdir 里修改。对应用来说它感觉不到这个过程但对系统设计者来说这个机制简直是为恢复出厂量身定做的。4.2 用 OverlayFS 做恢复出厂的整体设计有了前面分区规划的铺垫OverlayFS 的方案就很清晰了rootfs 作为 lowerdir 只读挂载/overlay/upper 作为 upperdir/overlay/work 作为 workdir三者叠加后挂载成新的根目录。系统正常运行时的一切写操作都落在 /overlay/upper 里。恢复出厂的操作本质上就是“清空 /overlay 分区下的 upper 和 work 目录然后重启”。因为 lowerdir 一直没变清空上层之后看到的系统就是刚烧录时的样子。这套方案的优势非常明显恢复速度快即使 2GB 的根文件系统清空 overlay 也就几十毫秒加上重启也就几秒钟永远不需要写整个系统分区不消耗 eMMC 不必要的寿命不会出现“恢复过程中断电变砖”的风险因为只删了可写层系统层毫发无损用户数据全在 /data 分区恢复系统不会误删业务数据4.3 OverlayFS 挂载的实操配置要让根文件系统跑在 OverlayFS 上关键是在系统启动时完成一次重新挂载。我一般不用 initramfs而是直接在 U-Boot 启动参数里指定 overlay 逻辑或者在一个早起的 systemd 服务里完成。直接用 fstab 挂载 OverlayFS 有时会遇到顺序问题因为你要在根文件系统已经挂载的情况下把另一个文件系统当 lowerdir 叠上来这个操作在系统完全启动后再做会非常别扭。所以我的做法是早期启动脚本或 initramfs里完成重挂载。以 systemd 为例在系统启动早期加入一个服务# /etc/systemd/system/overlay-root.service [Unit] DescriptionSetup overlay root filesystem DefaultDependenciesno Beforesysinit.target [Service] Typeoneshot RemainAfterExityes ExecStart/usr/local/bin/setup-overlay-root.sh脚本内容#!/bin/bash # setup-overlay-root.sh ROOT_DEVICE/dev/mmcblk0p2 OVERLAY_DEVICE/dev/mmcblk0p4 UPPER_DIR/overlay/upper WORK_DIR/overlay/work MERGED_DIR/mnt/root # 等待设备节点就绪 sleep 1 # 挂载 overlay 分区 mount $OVERLAY_DEVICE /overlay # 初始化 upper 和 work 目录 mkdir -p $UPPER_DIR $WORK_DIR $MERGED_DIR # 将当前根文件系统重新绑定挂载到临时目录作为 lower mount --bind / $MERGED_DIR mount --make-private $MERGED_DIR # 用 overlay 重新挂载根目录 mount -t overlay overlay -o lowerdir$MERGED_DIR,upperdir$UPPER_DIR,workdir$WORK_DIR / echo Overlay root mounted这里有几个容易踩的坑我逐个说明第一个坑mount --bind / $MERGED_DIR这一步必须有。如果你直接把lowerdir/写到 overlay 挂载参数里内核会陷入递归循环——overlay 的底层又依赖 overlay。必须先把当前根目录绑定到一个临时挂载点再用这个临时挂载点当 lowerdir最后用 overlay 覆盖根目录。第二个坑overlay 分区必须先挂载然后才能初始化 upper/work 目录。我见过有人直接在脚本里mkdir -p /overlay/upper但 /overlay 目录本身在 rootfs 里rootfs 还是只读的创建不了所以必须先 mount 一个可写分区到 /overlay。第三个坑如果 rootfs 本身不是只读挂载overlay 的 lower 和 upper 都在同一个可写文件系统上会破坏 OverlayFS 的一致性。所以/etc/fstab里 rootfs 的挂载参数一定要写ro。4.4 恢复出厂的触发方式与脚本恢复出厂的核心动作是清空 upper 和 work。但要注意你不能在系统运行、overlay 已经挂载到根目录的时候直接删 upper 目录——因为当前根目录的写入会实时落到 upper删了又会立刻生成新的文件而且可能破坏正在运行的文件句柄。正确做法是不直接在线清理而是通过 reboot 配合标志位实现。我在方案里设置了三种触发方式方式一开机按键触发U-Boot 检测到某个 GPIO 按键被按下就在启动参数里传一个factory_reset标志。启动脚本里判断到这个标志后在 overlay 尚未挂载时清空 overlay 分区然后正常启动系统。方式二系统内指令触发用户或运维人员登录系统后执行factory-reset命令。命令的核心逻辑是把标志写入 /data 或专门的状态分区然后重启。启动早期脚本检测到标志后执行清理#!/bin/bash # /usr/local/bin/factory-reset touch /data/.factory_reset sync reboot然后启动脚本中if [ -f /data/.factory_reset ]; then echo Factory reset requested... umount -l /overlay 2/dev/null || true mkfs.ext4 -q /dev/mmcblk0p4 rm -f /data/.factory_reset sync fi这里我用 mkfs.ext4 直接格式化 overlay 分区比一个一个删文件干净利落也避免了文件系统碎片问题。要注意的是mkfs 会直接重建文件系统所以这一步绝不能在对 overlay 分区有挂载时执行否则内核会报错。所以我把清理动作放在 overlay 尚未挂载的启动早期。方式三Web/应用界面触发通过设备的业务 Web 页面或上位机软件调用一个后端接口后端只执行上面那个 factory-reset 脚本。这个对客户来说最友好因为不需要懂 Linux 命令。4.5 恢复出厂的边界条件与保护恢复出厂不是万能的我在设计时明确划分了边界rootfs 与系统内核损坏OverlayFS 只保护用户态文件内核和 bootloader 损坏时只能靠双分区回滚或串口刷机/data 分区用户数据默认保留因为很多工控场景设备有自己的配置和校准数据恢复出厂不能把这些丢掉如果业务确实需要“完整恢复”可以在 factory-reset 脚本里加一个参数选择是否同时格式化 /data硬件故障eMMC 物理损坏、供电异常、主板问题软件方案都无能为力还要提一点恢复出厂功能要“防呆”。我在脚本里加了一个二次确认机制比如需要先执行factory-reset --yes --confirm才能触发避免对面的运维手滑把几十条产线设备全恢复了。5. 常见问题与排查技巧实录5.1 故障现象速查表现象可能原因排查方向系统正常启动但修改配置后重启丢失overlay 挂载失败或 upper 没生效检查 /etc/fstab、检查启动日志中 overlay mount 的输出执行恢复出厂后系统还是旧状态upper 目录没清理干净或清理顺序错误确认清理时 overlay 未挂载确认 mkfs 目标分区正确升级完成后重启还是旧版本启动槽位标记没写成功检查 active_slot 文件内容检查 U-Boot 读取逻辑升级 B 分区后无法启动内核/设备树与 rootfs 不匹配检查 kernel_b.itb 是否写入 boot 分区检查根参数系统运行几个月后 eMMC 写满或变慢日志/缓存写入量过大且未限制检查 /var/log 大小、journald 占用、数据库文件位置OverlayFS 挂载时报 invalid argumentlowerdir 和 upperdir 同分区或 rootfs 未只读检查 fstab 中 ro 参数检查分区挂载情况恢复出厂后 /data 也没了格式化了错误的分区检查脚本中 mkfs 的分区编号加保护性判断5.2 几个值得记录的踩坑过程坑一journald 差点写废 eMMC我在一个项目上用了默认的 systemd-journald日志直接写到 /var/log/journal。设备现场跑了一个月后发现 eMMC 的写入量惊人一查 journald 默认没有日志大小上限滚动不够及时。后来我把 /var/log 改成 tmpfsjournald 的 Storagevolatile同时把需要持久化的应用日志单独用 logrotate 控制写入量立刻降下来了。坑二OverlayFS 和 rootfs 同分区的严重问题早期为了省分区我把 overlay 的 upper 目录放在了 rootfs 分区里一个叫 /overlay 的目录下。结果有个系统服务往 /etc 写了个文件copy-up 正确处理还行但一旦某个进程直接通过底层分区的路径改文件整个 overlay 视图就乱了。那时候排查了很久最后才意识到是 lower 和 upper 物理同盘造成的。这个问题从根上解决就是分一个独立分区给 overlay。坑三双分区升级断电后的“假成功”升级脚本里我以前是把“写 active_slot 标记”放在“拷贝系统文件”之后的同一段流程里但两次 sync 之间没有区分优先级。有一次客户升级写入 rootfs_b 时断电重启后 U-Boot 识别到 active_slot 还是 A系统正常工作可升级记录却显示“已写入新版本”运维误以为升级完成了。后来我改成升级包安装完成后单独弹一个“需要重启才能完成”的提示并且 active_slot 的写入状态会校验文件系统完整性后才确认成功。坑四恢复出厂时忘了 umount overlay有一次线上版本故障现场同事执行恢复出厂脚本里没有先 umount overlay 就删上层目录结果系统内核报错、文件系统只读最后只能断电重启。当时我意识到这个问题的严重性直接删一个挂载中的 overlay 上层等于在高速公路上换轮胎。后来脚本里一律先处理挂载状态再格式化。5.3 让系统“自己会看病”最后分享一个我觉得很值的做法在系统启动早期加一个健康检查脚本检查几个关键路径是否可写、关键服务是否存活、磁盘剩余空间是否充足。如果连续多次启动失败自动触发恢复出厂——当然要加保护比如只有连续 3 次失败才触发且必须是在/data 之外的系统分区空间足够时才执行。我还在设备上写了一个小工具syscheck会在开机时输出一张摘要rootfs 是否只读、overlay 是否挂载、当前启动槽位、磁盘空间、内核版本、固件版本。这大大减轻了排障时和现场沟通的负担。很多问题运维只需要把 syscheck 的输出发过来我就知道是哪一类故障了。写在后面这套存储配置、双分区升级加 OverlayFS 恢复出厂的方案我前前后后在不同项目里改了好几版踩过的坑比写出来的还多。核心体会就是工控设备的系统设计别想着“出事以后能修”而是要“出事以后不用修或者最简单操作就能恢复”。把只读、分区隔离、双分区、overlay 这几个机制吃透从存储规划开始就按这个思路做后面恢复出厂只是水到渠成的一步。最后再提一个我在调试时常用的技巧最终验证 OverlayFS 是否真生效可以在系统启动后执行df -h /和mount | grep overlay看到根目录挂载类型是 overlay 就说明成功如果要看某个文件到底落在 upper 还是 lower用ls -i对比文件 inode 和上下层目录是否一致就行。这个小办法帮我避过不少“以为生效其实没生效”的坑。 工控单板Linux存储规划与OverlayFS恢复出厂实战
在工控行业里摸爬滚打这几年接触最多的就是各种单板跑 Linux 的设备工业 HMI、边缘采集网关、运动控制板还有一堆叫不上名字的专用终端。这类设备和开发板最大的区别在于它是要 7x24 小时在现场跑的而且维护人员的水平参差不齐现场环境更是恶劣——突然断电、灰尘、震动、高温都是家常便饭。所以这里跑 Linux 不能照搬服务器那一套也不能照着树莓派的做法来存储配置、系统升级、故障恢复这套东西必须从设计之初就严丝合缝地规划好。这篇主要讲三个核心问题存储怎么分区才扛得住工控环境、系统怎么升级才安全可回滚、以及如何用 OverlayFS 实现一个真正好用的“恢复出厂”功能。这套组合拳我在多个项目里验证过从瑞芯微到全志再到几款国产 x86 板子都试过逻辑是通用的具体参数我会尽量给全。1. 工控单板 Linux 的整体设计与存储思路1.1 工控单板到底特殊在哪里工控单板和我们平时玩的树莓派、香橙派看着像实际上设计逻辑完全不一样。开发板强调折腾工控板强调稳定。客户现场装上去的设备少则三年多则五年八年不关机系统崩溃一次可能就是产线停线、数据丢失代价非常大。所以在做这类系统时第一原则就是默认你已经遇到了最坏的情况。比如客户可能会在系统正在写日志的时候直接断电可能会拿着 U 盘拷数据把系统文件误删可能会反复升级失败然后怪你产品不行。我们要做的不是祈祷这些事不发生而是让系统在遭遇这些事之后还能自己恢复或者用一个简单的操作就能恢复。另一个工控场景的特殊之处是网络环境。很多工厂的内网是隔离的设备根本访问不了外网。这意味着系统更新不能依赖在线软件源必须走离线升级包。也正因如此我们的存储规划里通常会为系统备份、升级包缓存预留一部分空间。1.2 存储介质选型eMMC 是绝对主流工控单板的存储介质就那么几类我把这几年的选型经验整理出来存储介质优点缺点工控场景建议eMMC内置坏块管理、抗震动、寿命较好、价格适中容量相对固定、磨损仍存在首选系统盘和数据盘都合适SD/TF 卡容量大、更换方便容易被弹出、接触不良、寿命参差不齐千万别当作系统盘最多做扩展存储SATA/NVMe SSD容量大、速度快成本高、体积大、功耗高数据量大的设备可选但要注意掉电保护SPI NOR Flash寿命长、启动快、可靠性极高容量太小通常几 MB 到几十 MB只放 bootloader 和硬件参数NAND Flash成本低、容量适中需要软件做坏块管理、有 OOB 区问题老平台还在用新设计不如直接用 eMMC从可靠性角度来说eMMC 赢在封装一体化和内置 FTL闪存转换层。它里面有独立的控制器管理逻辑块到物理块的映射、磨损均衡、坏块替换这些对上层应用是透明的。你写数据时不用关心底层擦写次数只要关注自己软件的写入量是否合理。我踩过的坑是 SD 卡做系统盘。某项目为了省成本用了工业级 SD 卡结果客户现场设备震动大SD 卡偶尔接触不良系统直接 I/O 错误崩溃而且恢复起来很麻烦。后来换 eMMC 方案再没出过这个问题。1.3 存储可靠性是恢复出厂的基石很多人在做“恢复出厂”功能时脑子里想到的是备份一个系统镜像出问题再用镜像恢复。这个思路没错但如果在存储规划阶段没做好后面全是麻烦。最基本的逻辑是恢复出厂要恢复到一个“干净”的状态那么这个干净状态就必须是物理隔离的、不被日常运行污染的。如果你把根文件系统和用户数据混在一个可写分区里所谓恢复出厂就只能靠完整重刷整个分区——这样既慢又容易出问题而且会把不该清的用户数据也抹掉。所以在我的设计里系统恢复的关键不是一个“救火”脚本而是存储布局本身系统区保持只读可写数据集中在独立的 data 分区运行时改动放到 OverlayFS 的上层。这样恢复出厂只需要清理 OverlayFS 的上层目录秒级完成而且用户数据可以保留。2. 存储配置分区规划与读写控制2.1 典型工控单板分区规划以一块 8GB eMMC、跑 Debian/Ubuntu 系统的工控单板为例我习惯的分区方案是这样的分区大小文件系统挂载点读写属性说明/dev/mmcblk0p1256MBext4/bootro内核、设备树、启动参数/dev/mmcblk0p22GBext4/ (rootfs)ro可通过 overlay 变可写系统根文件系统/dev/mmcblk0p3512MBext4/datarw应用配置、用户数据、日志缓存/dev/mmcblk0p4512MBext4/overlayrwOverlayFS 的 upper 与 work 目录/dev/mmcblk0p5512MBext4/mnt/backuprw出厂备份与升级包暂存区剩余空间视 eMMC 容量ext4/home 或 /var/lib/dockerrw业务数据扩展区这个分区表看着简单但每个分区的读写属性都是刻意设计的。rootfs 默认只读挂载所有系统文件不会被篡改/data 保存需要持久化的用户数据即使恢复出厂也能保留/overlay 专门给 OverlayFS 当可写层是“恢复出厂”功能的核心。分区空间虽然不大但对工控系统来说完全够用——系统目录几百 MB 就装完了。容量较大的 eMMC16GB/32GB可以在后面加一个大分区给业务数据或者拆成多个逻辑分区给 Docker 用。2.2 让根文件系统“真的只读”把 rootfs 挂载为只读这件事说易行难很多人改了 /etc/fstab 后发现系统起不来或者一堆服务报错。原因在于很多应用和系统服务默认就要往 / 里面写东西——/var/log 要写日志、/run 要写运行时文件、/tmp 要放临时文件、/etc 有时要改配置。我用的方案是“rootfs 只读 关键路径 tmpfs 覆盖”。具体做法# /etc/fstab 关键部分 /dev/mmcblk0p2 / ext4 defaults,noatime,ro 0 1 tmpfs /tmp tmpfs defaults,size64M,mode1777 0 0 tmpfs /var/log tmpfs defaults,size32M,mode0755 0 0 tmpfs /var/tmp tmpfs defaults,size16M,mode1777 0 0然后把 /var/log 里的系统日志通过 rsyslog 配置写到 /data/logs 或者一个独立的数据分区。systemd-journald 也要改 Storage 配置避免它往 /var/log/journal 写东西。另外/etc 下面有些运行时配置需要可写比如 DHCP 申请的 DNS、某些软件的许可证文件。我一个项目里的处理是把所有“运行时要动态写入 /etc 的文件”统一重定向到 /data/etc 下用完再通过 bind mount 回填mkdir -p /data/etc mount --bind /data/etc /etc/network这样 rootfs 的只读不会被打破而业务上需要的“可写”又都能满足。第一次调的时候挺折腾但调好之后省心太多了。2.3 日志轮转与写入量控制工控设备最怕的不是系统文件被改而是闪存被写坏。eMMC 虽然有磨损均衡但也是有寿命的一个严重的日志死循环可以在几个月内干掉一块好好的 eMMC。处理思路就两条少写、限速。少写是指日志和临时文件不要落在持久化介质上用 tmpfs 顶住限速是必须写持久化的日志时用 logrotate 按大小和份数轮转避免无限增长。我常用的配置/var/log/app/*.log { daily rotate 14 maxsize 64M compress copytruncate missingok }还有一个容易忽略的地方数据库和缓存。如果设备上有 SQLite 或者一些 KV 存储一定要把库文件放到 /data 而不是 /root 或 /var/lib。SQLite 的 WAL 模式会频繁写盘对闪存寿命很不友好如果业务允许尽量用内存库定时刷盘或者调大 checkpoint 间隔。2.4 为什么强调物理分区隔离我这里说的“物理分区隔离”是指 rootfs、overlay 上层、用户数据必须放在三个独立分区而不是同一个分区下的三个目录。原因在于OverlayFS 的 upper 目录如果和 lower 的底层分区是同一个文件系统且该文件系统是可写的那么一旦 rootfs 里有文件被修改底层的 lower 就被污染了最终 OverlayFS 的合并视图会非常混乱。实际做过实验rootfs 和 overlay 在同一分区时如果系统服务不小心往 / 下写了一个和 lower 中同名文件OverlayFS 的 copy-up 逻辑会被绕过底层文件直接被改掉。等你想做恢复出厂、清空 upper 时发现底层文件也变了恢复到的是一个不干净的状态。分区隔离之后这个问题彻底消失。upper 的改动永远只落在自己的分区里和 lower 底层互不干扰。3. 系统升级实操离线升级与双分区切换3.1 为什么工控升级必须走离线包在线升级方便但工控现场真的不适合。工业网络往往有严格的隔离策略设备可能连网关都不通即便能联网也不能保证目标设备能稳定地从服务器拉取大量数据。更实际的一点是工控系统的升级行为需要可审计、可重复、可回滚。我接触过的客户升级都要求有明确的版本号、升级记录、操作日志这些在线升级很难给到。所以我一般采用离线升级包 双分区切换的方案。升级包是一个带校验信息的 tar.gz或者更规范一点是一个自解压的升级脚本集合里面包含完整的文件系统镜像、内核、设备树、升级脚本和校验文件。3.2 双分区A/B升级的原理与优势双分区升级的思路很直白把 rootfs 分成 A、B 两份当前运行的是 A升级时往 B 里写写完验证无误后把启动标志切到 B重启后 U-Boot 从 B 启动。如果 B 启动失败U-Boot 检测到启动次数异常自动回滚到 A。这个方案的优点在于升级过程对当前运行的系统完全无影响即使升级写到一半断电A 系统依然完好即使 B 系统起来后有问题也能自动回滚不会变砖。对工控设备来说这个“保底”太重要了。具体到分区规划就是在前面那个表的基础上再加一个 rootfs_b分区大小挂载点说明/dev/mmcblk0p22GB/ (rootfs_a)当前运行的系统/dev/mmcblk0p32GB/mnt/rootfs_b备用系统升级目标启动槽位的记录我放在 /boot 分区下一个文件里U-Boot 通过读取这个文件决定从哪个 rootfs 加载。也可以把启动槽位存在 U-Boot 环境变量或 misc 分区看你的引导链怎么设计方便。3.3 离线升级脚本的设计与实现升级脚本是整个升级流程的核心。我的升级包结构长这样upgrade_package/ ├── VERSION ├── checksums.md5 ├── rootfs_b.tar.gz ├── kernel.itb ├── u-boot.bin └── upgrade.shupgrade.sh 的关键逻辑如下简化版#!/bin/bash set -euo pipefail INACTIVE_ROOT/dev/mmcblk0p3 MNT_ROOT/mnt/upgrade_root BOOT_DIR/boot echo Upgrade script start # 1. 校验升级包完整性 md5sum -c checksums.md5 if [ $? -ne 0 ]; then echo Checksum failed. Abort. exit 1 fi # 2. 检查备用分区是否可写先卸载再挂载 umount $MNT_ROOT 2/dev/null || true mount $INACTIVE_ROOT $MNT_ROOT # 3. 清空目标分区 rm -rf $MNT_ROOT/* # 4. 解压文件系统 tar xzf rootfs_b.tar.gz -C $MNT_ROOT sync # 5. 写入内核/设备树到 boot 分区 cp kernel.itb $BOOT_DIR/kernel_b.itb sync # 6. 写入启动槽位标记 echo B $BOOT_DIR/active_slot sync # 7. 卸载并完成 umount $MNT_ROOT echo Upgrade done, reboot to activate 这里最关键的一步是第 6 步——只有系统文件全部写完后才修改启动槽位标记。如果第 5 步或者第 6 步之前断电重启系统还按旧槽位启动升级失败但原系统不损坏如果第 6 步之后断电B 分区已经有了完整系统启动后进入新版本本身也没问题。这就是“先写数据、后写标志”的断电保护策略。3.4 U-Boot 侧的双分区引导与自动回滚U-Boot 侧的引导逻辑要配合启动槽位标记工作。以最简单的方案为例U-Boot 环境变量 bootcmd 中做一次检测if test -f ${bootpart}/active_slot; then slot$(cat ${bootpart}/active_slot) else slotA fi if test ${slot} B; then setenv rootspec root/dev/mmcblk0p3 rootfstypeext4 else setenv rootspec root/dev/mmcblk0p2 rootfstypeext4 fi自动回滚的原理也很简单在 B 系统正常启动且健康检查通过后在 Linux 里把一个“标记文件”写到 boot 分区表示这次启动是成功启动U-Boot 每次启动时检查如果指定槽位没有成功标记且启动次数达到阈值就回退到另一个槽位# 在系统启动脚本中执行 if [ -f /boot/active_slot ]; then slot$(cat /boot/active_slot) touch /boot/${slot}_boot_ok # 清理失败计数 setenv -f bootcount 0 fiU-Boot 中对应逻辑if test -f ${bootpart}/B_boot_ok; then setenv slot B elif test ${bootcount} -ge 2; then echo Boot B failed, rollback to A setenv slot A setenv bootcount 0 fi这套机制我在实际项目中跑了一年多客户那边也有过几次升级失败的情况基本都是 U-Boot 自动回滚到旧版本解决的运维同学反馈“体验还可以重启一下就好了”。3.5 简化版方案单分区 备份包恢复如果你的 eMMC 空间紧张或者产品定位里不太需要反复升级也可以用简化方案rootfs 只保留一份但在 /backup 分区保存一个出厂时的 rootfs 镜像。升级时对当前 rootfs 做覆盖失败时从备份包恢复。这个方案的缺点是升级过程会打断业务而且覆盖写 rootfs 时如果断电会变砖要么靠备份恢复要么靠刷机工具救砖可靠性明显低于双分区。所以我的建议是只要能承担几百 MB 的空间成本优先上双分区空间实在紧张的再考虑简化版。4. OverlayFS 恢复出厂原理与实操4.1 OverlayFS 到底是个什么东西OverlayFS 是 Linux 内核自带的一种联合文件系统作用是“把两个目录叠在一起看”。这里用一个生活化类比想象你有一张写满字的纸lowerdir只读底层又拿来一张半透明的纸upperdir可写上层盖在上面。你透过上面那张纸看到的是两张纸叠加后的效果下面的字能看见上面的字也能看见。如果我在上面的纸上写字不会影响到下面那张纸如果我把上面那张纸揭开丢掉换一张新的半透明纸盖上去看到的又变回最初那一层的内容——这不就是恢复出厂吗。在内核层面OverlayFS 有四个关键目录目录作用生命周期lowerdir只读底层一般是根文件系统永远不变upperdir可写上层所有修改都在这里恢复出厂时清空workdirOverlayFS 元数据工作目录恢复出厂时清空merged叠加视图应用实际读取/写入的地方动态生成当应用修改一个 lowerdir 里的文件时OverlayFS 会先把该文件“复制”到 upperdir这叫 copy-up再在 upperdir 里修改。对应用来说它感觉不到这个过程但对系统设计者来说这个机制简直是为恢复出厂量身定做的。4.2 用 OverlayFS 做恢复出厂的整体设计有了前面分区规划的铺垫OverlayFS 的方案就很清晰了rootfs 作为 lowerdir 只读挂载/overlay/upper 作为 upperdir/overlay/work 作为 workdir三者叠加后挂载成新的根目录。系统正常运行时的一切写操作都落在 /overlay/upper 里。恢复出厂的操作本质上就是“清空 /overlay 分区下的 upper 和 work 目录然后重启”。因为 lowerdir 一直没变清空上层之后看到的系统就是刚烧录时的样子。这套方案的优势非常明显恢复速度快即使 2GB 的根文件系统清空 overlay 也就几十毫秒加上重启也就几秒钟永远不需要写整个系统分区不消耗 eMMC 不必要的寿命不会出现“恢复过程中断电变砖”的风险因为只删了可写层系统层毫发无损用户数据全在 /data 分区恢复系统不会误删业务数据4.3 OverlayFS 挂载的实操配置要让根文件系统跑在 OverlayFS 上关键是在系统启动时完成一次重新挂载。我一般不用 initramfs而是直接在 U-Boot 启动参数里指定 overlay 逻辑或者在一个早起的 systemd 服务里完成。直接用 fstab 挂载 OverlayFS 有时会遇到顺序问题因为你要在根文件系统已经挂载的情况下把另一个文件系统当 lowerdir 叠上来这个操作在系统完全启动后再做会非常别扭。所以我的做法是早期启动脚本或 initramfs里完成重挂载。以 systemd 为例在系统启动早期加入一个服务# /etc/systemd/system/overlay-root.service [Unit] DescriptionSetup overlay root filesystem DefaultDependenciesno Beforesysinit.target [Service] Typeoneshot RemainAfterExityes ExecStart/usr/local/bin/setup-overlay-root.sh脚本内容#!/bin/bash # setup-overlay-root.sh ROOT_DEVICE/dev/mmcblk0p2 OVERLAY_DEVICE/dev/mmcblk0p4 UPPER_DIR/overlay/upper WORK_DIR/overlay/work MERGED_DIR/mnt/root # 等待设备节点就绪 sleep 1 # 挂载 overlay 分区 mount $OVERLAY_DEVICE /overlay # 初始化 upper 和 work 目录 mkdir -p $UPPER_DIR $WORK_DIR $MERGED_DIR # 将当前根文件系统重新绑定挂载到临时目录作为 lower mount --bind / $MERGED_DIR mount --make-private $MERGED_DIR # 用 overlay 重新挂载根目录 mount -t overlay overlay -o lowerdir$MERGED_DIR,upperdir$UPPER_DIR,workdir$WORK_DIR / echo Overlay root mounted这里有几个容易踩的坑我逐个说明第一个坑mount --bind / $MERGED_DIR这一步必须有。如果你直接把lowerdir/写到 overlay 挂载参数里内核会陷入递归循环——overlay 的底层又依赖 overlay。必须先把当前根目录绑定到一个临时挂载点再用这个临时挂载点当 lowerdir最后用 overlay 覆盖根目录。第二个坑overlay 分区必须先挂载然后才能初始化 upper/work 目录。我见过有人直接在脚本里mkdir -p /overlay/upper但 /overlay 目录本身在 rootfs 里rootfs 还是只读的创建不了所以必须先 mount 一个可写分区到 /overlay。第三个坑如果 rootfs 本身不是只读挂载overlay 的 lower 和 upper 都在同一个可写文件系统上会破坏 OverlayFS 的一致性。所以/etc/fstab里 rootfs 的挂载参数一定要写ro。4.4 恢复出厂的触发方式与脚本恢复出厂的核心动作是清空 upper 和 work。但要注意你不能在系统运行、overlay 已经挂载到根目录的时候直接删 upper 目录——因为当前根目录的写入会实时落到 upper删了又会立刻生成新的文件而且可能破坏正在运行的文件句柄。正确做法是不直接在线清理而是通过 reboot 配合标志位实现。我在方案里设置了三种触发方式方式一开机按键触发U-Boot 检测到某个 GPIO 按键被按下就在启动参数里传一个factory_reset标志。启动脚本里判断到这个标志后在 overlay 尚未挂载时清空 overlay 分区然后正常启动系统。方式二系统内指令触发用户或运维人员登录系统后执行factory-reset命令。命令的核心逻辑是把标志写入 /data 或专门的状态分区然后重启。启动早期脚本检测到标志后执行清理#!/bin/bash # /usr/local/bin/factory-reset touch /data/.factory_reset sync reboot然后启动脚本中if [ -f /data/.factory_reset ]; then echo Factory reset requested... umount -l /overlay 2/dev/null || true mkfs.ext4 -q /dev/mmcblk0p4 rm -f /data/.factory_reset sync fi这里我用 mkfs.ext4 直接格式化 overlay 分区比一个一个删文件干净利落也避免了文件系统碎片问题。要注意的是mkfs 会直接重建文件系统所以这一步绝不能在对 overlay 分区有挂载时执行否则内核会报错。所以我把清理动作放在 overlay 尚未挂载的启动早期。方式三Web/应用界面触发通过设备的业务 Web 页面或上位机软件调用一个后端接口后端只执行上面那个 factory-reset 脚本。这个对客户来说最友好因为不需要懂 Linux 命令。4.5 恢复出厂的边界条件与保护恢复出厂不是万能的我在设计时明确划分了边界rootfs 与系统内核损坏OverlayFS 只保护用户态文件内核和 bootloader 损坏时只能靠双分区回滚或串口刷机/data 分区用户数据默认保留因为很多工控场景设备有自己的配置和校准数据恢复出厂不能把这些丢掉如果业务确实需要“完整恢复”可以在 factory-reset 脚本里加一个参数选择是否同时格式化 /data硬件故障eMMC 物理损坏、供电异常、主板问题软件方案都无能为力还要提一点恢复出厂功能要“防呆”。我在脚本里加了一个二次确认机制比如需要先执行factory-reset --yes --confirm才能触发避免对面的运维手滑把几十条产线设备全恢复了。5. 常见问题与排查技巧实录5.1 故障现象速查表现象可能原因排查方向系统正常启动但修改配置后重启丢失overlay 挂载失败或 upper 没生效检查 /etc/fstab、检查启动日志中 overlay mount 的输出执行恢复出厂后系统还是旧状态upper 目录没清理干净或清理顺序错误确认清理时 overlay 未挂载确认 mkfs 目标分区正确升级完成后重启还是旧版本启动槽位标记没写成功检查 active_slot 文件内容检查 U-Boot 读取逻辑升级 B 分区后无法启动内核/设备树与 rootfs 不匹配检查 kernel_b.itb 是否写入 boot 分区检查根参数系统运行几个月后 eMMC 写满或变慢日志/缓存写入量过大且未限制检查 /var/log 大小、journald 占用、数据库文件位置OverlayFS 挂载时报 invalid argumentlowerdir 和 upperdir 同分区或 rootfs 未只读检查 fstab 中 ro 参数检查分区挂载情况恢复出厂后 /data 也没了格式化了错误的分区检查脚本中 mkfs 的分区编号加保护性判断5.2 几个值得记录的踩坑过程坑一journald 差点写废 eMMC我在一个项目上用了默认的 systemd-journald日志直接写到 /var/log/journal。设备现场跑了一个月后发现 eMMC 的写入量惊人一查 journald 默认没有日志大小上限滚动不够及时。后来我把 /var/log 改成 tmpfsjournald 的 Storagevolatile同时把需要持久化的应用日志单独用 logrotate 控制写入量立刻降下来了。坑二OverlayFS 和 rootfs 同分区的严重问题早期为了省分区我把 overlay 的 upper 目录放在了 rootfs 分区里一个叫 /overlay 的目录下。结果有个系统服务往 /etc 写了个文件copy-up 正确处理还行但一旦某个进程直接通过底层分区的路径改文件整个 overlay 视图就乱了。那时候排查了很久最后才意识到是 lower 和 upper 物理同盘造成的。这个问题从根上解决就是分一个独立分区给 overlay。坑三双分区升级断电后的“假成功”升级脚本里我以前是把“写 active_slot 标记”放在“拷贝系统文件”之后的同一段流程里但两次 sync 之间没有区分优先级。有一次客户升级写入 rootfs_b 时断电重启后 U-Boot 识别到 active_slot 还是 A系统正常工作可升级记录却显示“已写入新版本”运维误以为升级完成了。后来我改成升级包安装完成后单独弹一个“需要重启才能完成”的提示并且 active_slot 的写入状态会校验文件系统完整性后才确认成功。坑四恢复出厂时忘了 umount overlay有一次线上版本故障现场同事执行恢复出厂脚本里没有先 umount overlay 就删上层目录结果系统内核报错、文件系统只读最后只能断电重启。当时我意识到这个问题的严重性直接删一个挂载中的 overlay 上层等于在高速公路上换轮胎。后来脚本里一律先处理挂载状态再格式化。5.3 让系统“自己会看病”最后分享一个我觉得很值的做法在系统启动早期加一个健康检查脚本检查几个关键路径是否可写、关键服务是否存活、磁盘剩余空间是否充足。如果连续多次启动失败自动触发恢复出厂——当然要加保护比如只有连续 3 次失败才触发且必须是在/data 之外的系统分区空间足够时才执行。我还在设备上写了一个小工具syscheck会在开机时输出一张摘要rootfs 是否只读、overlay 是否挂载、当前启动槽位、磁盘空间、内核版本、固件版本。这大大减轻了排障时和现场沟通的负担。很多问题运维只需要把 syscheck 的输出发过来我就知道是哪一类故障了。写在后面这套存储配置、双分区升级加 OverlayFS 恢复出厂的方案我前前后后在不同项目里改了好几版踩过的坑比写出来的还多。核心体会就是工控设备的系统设计别想着“出事以后能修”而是要“出事以后不用修或者最简单操作就能恢复”。把只读、分区隔离、双分区、overlay 这几个机制吃透从存储规划开始就按这个思路做后面恢复出厂只是水到渠成的一步。最后再提一个我在调试时常用的技巧最终验证 OverlayFS 是否真生效可以在系统启动后执行df -h /和mount | grep overlay看到根目录挂载类型是 overlay 就说明成功如果要看某个文件到底落在 upper 还是 lower用ls -i对比文件 inode 和上下层目录是否一致就行。这个小办法帮我避过不少“以为生效其实没生效”的坑。