overlayfs实战：为嵌入式Linux只读根文件系统打造可写分区与自动挂载

1. 项目概述：只读根文件系统的破局方案

先说清楚这个项目到底是干嘛的。你在嵌入式设备、路由器、树莓派这类平台上鼓捣过Linux的话，大概率遇到过一个问题：固件把根文件系统锁成了只读，一切改动重启后归零。装个软件、改个配置、留下点日志，统统没法持久化。要解决这个麻烦，最常用也最优雅的方案就是给系统搞一个overlay分区，把原本只读的根目录作为底层，在之上叠加一个可写层，让你既能用原厂固件，又能保留自己的数据。

我做这个项目的起因也很实际。某开发板自带的系统是只读的，每次调试网络配置都要把改动写进SD卡再重新刷固件，效率低到让人崩溃。于是我就研究怎么用overlayfs来实现“只读根文件系统＋可写数据层”的组合，做完之后整个系统的可用性提升了一大截。这个方案适合嵌入式Linux开发者、树莓派玩家、路由器折腾爱好者，也适合做设备定制维保的技术人。

核心关键词其实就三个：overlayfs、分区规划、启动自动挂载。把这三件事理清楚，剩下的都是工程化细节。我在这篇文章里会把怎么做分区、怎么配置overlay参数、怎么让系统开机自动把overlay挂上去，每一步都拆开讲，附上我实际测试过的命令和参数，以及在调试过程中踩过的坑。

2. 核心思路解构：overlayfs原理与实际选型

2.1 overlayfs到底是怎么“叠”出可写层的

overlayfs是Linux内核提供的一种联合文件系统，说人话就是：把一个或多个只读目录作为底层，一个可写目录作为上层，然后把它们“合成”成一个新的挂载点。用户看到的就像是一个完整可写的文件系统，但底层文件其实基本没有动过，改动全部沉淀在上层目录里。

这里有几个关键概念必须搞清楚，否则后面配置肯定踩坑：

• lowerdir：底层目录，可以是一个，也可以是多个。一般就是你的只读根文件系统。
• upperdir：上层目录，所有新增和改名后的文件都放这里。
• workdir：工作目录，负责做一些元数据同步和原子操作，必须和upperdir在同一个文件系统上。
• merged：合并之后的视图，也就是你最终挂载出来的那一整个目录。

我在这个项目中，把根文件系统整个作为lowerdir，然后把一个单独分出来的ext4分区挂载到/mnt/overlay，在这个分区里建upper和work子目录，最后把overlay挂到根目录/上。这样看起来根目录就能写了，所有新增和修改都落到了那块独立分区里。

mount -t overlay overlay / -o lowerdir=/,upperdir=/mnt/overlay/upper,workdir=/mnt/overlay/work

你可能要问：这不就是自己挂自己吗？底层是根目录本身，挂载点也是根目录，听起来有点玄幻。这在静态环境下确实可行，原理就是内核在挂载overlay时，会先对当前根文件系统做一个快照引用，然后把它当作lowerdir来使用。但在实际配置中，如果直接把这个命令塞进启动脚本，往往会有时序问题。所以更稳妥的做法是把overlay的挂载动作放在系统初始化早期阶段，并且使用mount命令的-o move或者配合switch_root这类工具来做。

2.2 为什么选择overlay而不是直接改rootfs

有人会想：既然要可写，直接把根文件系统挂成读写不就行了吗？何必绕一圈用overlay？

这个问题我问过自己很多次，最后得出的结论是：在很多固件化、镜像化的设备场景里，根文件系统被设计成只读是有意的，而不是没能力的。原因有几个。

第一，安全性。只读根文件系统意味着即使设备被入侵或误操作，核心系统文件无法被篡改。对公网暴露的设备来说，这是一道非常有效的防线。第二，稳定性。只读文件系统不会因为突然断电产生文件系统损坏，这是很多嵌入式设备长时间无人值守运行的底气。第三，升级机制。系统升级往往就是整块分区重写，只读设计让升级过程更简单，不用考虑旧数据清理的问题。

但只读系统也带来了一个明显的问题：用户没法用。

所以我需要的是“系统还是那个系统，但用户能写自己的东西”。overlay把这两件事完美分开了：系统部分保持只读，还能继续享受固件的升级和校验；用户数据落在upper层，专用分区管理。后续遇到固件升级的情况，只需要把旧upper层备份、格式化或者迁走，新固件启动后又是一套干净的系统，而用户配置可以按需恢复。这个“系统与数据分离”的设计，恰恰是overlay方案最核心的价值。

2.3 目录结构设计：不一次性留缓冲，预留迁移空间

在正式动手之前，我花了不少时间琢磨分区到底该怎么排。很多教程上来就是一句“新建一个分区格式化，挂载overlay”，真到生产环境会发现问题不少。

首先，你要弄清楚自己有多少存储空间可用。嵌入式设备一般会有SD卡、eMMC或NAND Flash，空间从几百MB到几十GB不等。如果设备原本只有一块SD卡，上面已经分了几个区，那你可能需要压缩已有分区、腾出空间新建一个，或者干脆用一个已经存在的空闲分区。这个过程中，分区大小的规划直接决定了你未来能存多少配置和日志。

另外一个容易被忽略的点是：留给overlay分区的空间，最好比你的“预期可写数据”大一点。比如你预期就要写几十MB的配置文件和状态文件，那overlay分区至少要给几百MB的余量。因为overlay的工作机制决定了，哪怕你只修改了一个二进制文件的几个字节，它也会在upper层复制一份完整的新文件，也就是说“一次修改、两份占用”。日志文件、包管理器缓存这类增长型数据，更是会在不知不觉中把upper层塞满。

我把两层都拆开设计：lower层保持出厂状态，upper层专门放自己的配置、软件和日志。这样出了问题，我可以单独处理upper层，甚至把它整个清空恢复，而不会连带底层系统一起搞坏。这个思想贯穿了我后续所有的项目设计，也建议你从第一步起就养成这种分层规划的习惯。

3. 前置检查与材料准备：内核、工具、存储一个都不能少

3.1 内核是否已经支持overlay

开始动手之前，我建议先做一个基础检查：你的内核是否编译了overlayfs支持。虽然很多主流发行版和开发板固件默认开启了CONFIG_OVERLAY_FS，但并不是所有精简内核都包含它。如果内核查不到这个模块，后续所有操作都是白搭。

cat /proc/filesystems | grep overlay

如果上面命令有输出，说明当前内核已经内置了对overlayfs的支持。如果没输出，再试试手动加载模块：

modprobe overlay

然后重新执行一次检查命令。如果说“module not found”或者grep结果仍然是空的，那就要考虑当前内核是不是被裁剪掉了overlayfs支持，需要用完整版内核，或者自己重新编译内核，把下面这个选项编译进去：

CONFIG_OVERLAY_FS=y

这个选项在File systems -> Overlay filesystem support下。有些厂商板子改内核源码比较麻烦，可以直接联系方案商要一个包含overlayfs的固件，或者用他们提供的OEM工具从BSP里把模块加回来。

3.2 分区工具的可用性

在只读根文件系统上，问题往往不是“你不会分区”，而是“你没有分区的工具”。如果你发现设备里没有fdisk、parted，不要慌，这是很常见的情况。精简系统里连sfdisk都可能被拿掉了。

我的经验是自己准备一套静态编译的工具，用busybox里面集成的fdisk也是一个好选择。把busybox复制到可写目录，就能在启动阶段完成分区。对于只有SD卡和eMMC的场景，sfdisk其实更顺手，因为它可以非交互式地一次性写入完整分区表：

sfdisk /dev/mmcblk0 << EOF ,200M,L ; EOF

上面这条命令的意思是给原设备重新分区：第一块分区大小200MB，第二个分区占满剩余空间。注意，这只是一个示例格式，具体分区表怎么排，得看你的原始系统结构和空间规划来做。

注意：对正在运行的设备做分区操作，改动之后系统通常识别不到新分区表，需要partprobe让内核重新读取，或者直接重启。而且，如果你动了系统所在分区的偏移量或者大小，可能直接导致系统起不来。所以在测试板上先演练一遍，是绝对必要的。

3.3 文件系统格式选择

overlayfs本身是不关心upper层和workdir介质格式的，它只要求这两个目录在同一个挂载点上，底层文件系统是ext4、f2fs、btrfs都行。实际操作中，我优先推荐ext4，原因很简单：成熟、稳定、工具链齐全、损坏恢复容易。

对于NAND Flash这类介质，f2fs更合适，因为它的设计初衷就是面向闪存设备的日志结构和磨损均衡。但f2fs的成熟度和救援工具有些时候不如ext4，如果设备上已经有一个ext4分区，直接复用它会更省心。

还有一部分特殊设计是把overlay直接做实现在tmpfs上的。tmpfs是基于内存的临时文件系统，挂载在/dev/shm这种位置，重启即失。有人会用它来做“内存盘型overlay”，让系统运行时表现为完全可写、但重启后恢复默认状态。这种用法在路由器急救系统、出厂演示模式里很常见，如果你正在做的是这种“假持久化”设计，storage介质部分就可以略过了。

4. 实操过程与核心环节实现：从分区到开机自动挂载

4.1 第一步：创建并格式化overlay分区

我拿一个典型的设备举例。假设它有一块eMMC，内部已经存在两个分区：第一个分区是kernel，第二个分区是只读rootfs。测试板上插着一张空闲的SD卡，我打算把整个SD卡作为overlay的存储区。

先把SD卡插进读卡器，确认设备节点：

lsblk

假设输出中SD卡被识别为/dev/mmcblk1，且无分区，那么我直接创建分区并格式化为ext4：

fdisk /dev/mmcblk1

在fdisk交互界面里依次输入n新建分区、p主分区、1分区编号、默认起始扇区、默认结束扇区，最后w写入分区表。之后格式化：

mkfs.ext4 -L overlay /dev/mmcblk1p1

需要注意的是，格式化之前务必确认设备节点没错。我做过的很多项目里，插卡之后SD卡是被识别成/dev/mmcblk0还是/dev/mmcblk1并不固定，它取决于系统枚举顺序。这一步错了，轻则格式错盘，重则把系统盘抹掉，没有任何挽回余地。

格式化完成后，把这个分区挂载到一个临时目录：

mount /dev/mmcblk1p1 /mnt/overlay

4.2 第二步：构造upper与work目录

overlayfs的upperdir和workdir需要位于同一个文件系统内。也就是说它们必须都在/mnt/overlay这个分区上，各自建一个目录：

mkdir /mnt/overlay/upper mkdir /mnt/overlay/work

需要注意work目录不是仅仅“临时中转站”那么简单。overlayfs在挂载时会在这个目录里做inode映射、复制和重命名操作，如果work目录所在文件系统空间不足或类型不匹配，挂载会直接失败。另外，work目录和upper目录不能在同一个目录树之外再有不同的挂载点层级，否则内核会拒绝挂载，报“directory on a different mount”之类的错误。

在真正挂载overlay之前，我还要处理一个隐藏问题：upper目录里必须预先存在和根目录顶层项目对应的目录结构。比如根目录下原有etc、usr、var、root、home这些目录，你要在upper里也建好这些空目录。否则，当你修改/etc/passwd时，overlayfs虽然能通过copy-up把原文件复制过来，但某些路径上的中间目录需要手动创建。

一个简单粗暴的办法是直接把根目录下所有顶层目录复制到upper：

cp -a /bin /etc /lib /root /home /usr /var /mnt/overlay/upper/

但这样会一次性把底层文件系统内容复制进upper，浪费空间。更合理的做法是让overlayfs自动copy-up需要的文件，事先只创建顶层目录骨架：

cd / for d in bin etc lib root home usr var srv opt; do mkdir -p /mnt/overlay/upper/$d 2>/dev/null done

这样upper目录只是一个完整的、空心的目录队列，真正写入时才通过copy-up从底层拉文件。这个策略在大分区上尤其重要，毕竟直接cp -a /是一次性把所有系统文件占用的空间都翻倍，没必要。

4.3 第三步：测试overlay挂载

在正式写入启动配置之前，我建议先手动挂载一次，确认参数无误。

创建一个临时合并点，比如/tmp/merged：

mkdir -p /tmp/merged mount -t overlay overlay /tmp/merged -o lowerdir=/,upperdir=/mnt/overlay/upper,workdir=/mnt/overlay/work

然后在/tmp/merged中测试写入：

touch /tmp/merged/overlay_test_file ls /mnt/overlay/upper/overlay_test_file

如果upper里能看到这个文件，说明copy-up路径正常。接着检查一下/下的文件是否能正常读取和复制，比如：

head -n 3 /tmp/merged/etc/hostname

如果一切正常，把overlay卸载：

umount /tmp/merged

这里有一个非常重要的细节：这个测试挂载点不能和最终的挂载点冲突。如果直接把overlay挂到/上而你还在/目录里执行命令，操作系统的动态库加载会出各种诡异问题，最典型的就是当前shell的所有命令都提示“Text file busy”或者直接段错误。原因是这条路径的文件在运行中被替换了，实际指向的逻辑块地址变了，导致访问不可靠。所以测试挂载一定要用独立的临时挂载点，不要在根目录上直接验证。

4.4 第四步：构造启动用init脚本

自动挂载的根本目标，是在系统启动早期、用户态服务启动之前，就把根目录切换成overlay形态。这样后面启动的服务看到的根目录就已经是可写的。

嵌入式Linux的启动方式差异很大。有的用busybox init，有的用systemd，有的干脆是内核启动参数指定init=/bin/bash，需要手工执行引导脚本。我这里以最常见的busybox init + inittab为例，说一下我怎么把它嵌入到启动流程。

首先编写一个脚本，比如放在/etc/init.d/overlay-mount.sh：

#!/bin/sh MOUNT_POINT=/dev/mmcblk1p1 STORAGE=/mnt/overlay UPPER=$STORAGE/upper WORK=$STORAGE/work ROOT_MERGE=/ if mountpoint -q $UPPER; then echo "overlay already mounted" exit 0 fi mount $MOUNT_POINT $STORAGE 2>/dev/null || { echo "Failed to mount overlay storage" exit 1 } mkdir -p $UPPER $WORK # 把根目录下关键顶层目录在upper中建好 for d in bin etc lib root home usr var srv opt tmp; do mkdir -p $UPPER/$d done mount -t overlay overlay $ROOT_MERGE -o lowerdir=/,upperdir=$UPPER,workdir=$WORK

然后把它加进启动流程。busybox init常见做法是在/etc/inittab里提前运行脚本，比如：

::sysinit:/etc/init.d/overlay-mount.sh

放在sysinit阶段，意味着它会在所有用户态服务开始前执行。

如果是systemd环境，更规范的做法是写一个mount unit，通过fstab自动挂载。不过嵌入式场景中，我还是更喜欢自己写脚本，因为可控性更强，出错时调试也直观。实际部署中，很多方案商的BSP会在initramfs阶段就做类似事情，这也是我把脚本最小化的原因，因为它大部分时候要跑在极简环境里。

4.5 第五步：把overlay挂载成根

这里值得展开讲一下，“把overlay挂到/”有三种常见实现方式。

方式一：直接挂到根目录。类似前面手测的命令，把/tmp/merged换成/。这种方式最直接，但启动早期，内核和init进程可能已经占用了根目录的文件句柄，直接挂载有时会失败，而且一旦失败会影响正在执行脚本的解释器。

方式二：使用pivot_root或switch_root。先在一个挂载点准备好overlay，然后通过switch_root把根目录切换到overlay所在目录。这种方式是initramfs阶段的标准做法，干净且安全。但如果你没有initramfs，而是一个直接挂载的rootfs，实现起来会额外复杂，需要先把原有的根重新挂载成可读，或者预先保留一个私有挂载点。

方式三：在kernel cmdline里指定。有些定制内核支持类似rootovl的启动参数，比如：

root=/dev/mmcblk0p2 rootfstype=ext4 rootflags=rw overlayroot=tmpfs

不过这需要内核/initramfs专门支持，不是通用做法。这里不做深究，毕竟我们在讨论一个手搓方案。

我个人的推荐是方式一配合systemd或者init脚本在启动最早期执行。只要你的rootfs不是“不可重新挂载为只读”的内核模块场景，大多数情况下都能成功。我在实际项目里，用方式一在busybox环境下连续测试多次，重启脚本执行顺序正确时成功率100%。失败通常出在部分版本的mount命令对overlay类型支持不完整，或者启动流程有其他脚本提前访问并占用了根目录文件。

如果方式一在你的板子上怎么都不成功，那就改用switch_root方案。其实很多发行版的initramfs框架已经封装好了这两个命令，你可以看它们的实现来理解整体过程。

4.6 第六步：让已有数据在overlay中可见

挂载完成之后，你可能很快发现一个问题：原有系统里的一些用户数据怎么不见了？

想象一下这个场景：原本系统里有/etc/passwd、/etc/shadow，这些文件在底层。你用overlay挂载之后，读写这些文件看到的底层数据是正常的，因为overlay会先检查upper层有没有同名文件，没有就映射到lower层。但有一种文件是例外，就是上层已经存在但底层数据还在更新的情况。例如，某个第三方服务会定期修改/etc/xxx.conf，但你又在upper层提前放置了新版本。这个时候文件更新会写入upper层，可参考的底层版本已经被遮蔽，恢复难度变大。

所以，挂载后做的第一件事，就是校准数据。对于原有的配置和服务状态，有几个路径需要单独处理：

• /etc：配置文件集中地，几乎每个服务都要读写这里。
• /var：日志、临时文件、状态文件。很多服务启动时会往/var下写pid文件。
• /home和/root：用户数据和ssh密钥。

由于upper层是全新目录，如果我不做处理，这些路径上的“旧数据”都会表现为系统默认值。比如你原来改过root密码、加了用户、配过网络，这些全部会失效。这也是为什么我在前面的脚本里，把etc、var、home、root这些目录预先在upper中创建好。目录存在，overlay在访问这些路径时，就能顺利地进行copy-up，把底层文件逐个复制到上层。没有目录，copy-up就不知道该往哪里复制，表现就是某些路径访问异常。

这里还有一个更细的优化：如果不希望某些文件被copy-up，比如日志目录或缓存目录，可以在upper中对应目录下放一个同名目录占位，并在挂载后把这个目录单独指向tmpfs或另一个专用分区。典型做法是：

mkdir -p /mnt/overlay/upper/var/log mount -t tmpfs tmpfs /var/log

这样日志写内存、重启清空，配置写磁盘、永久保留。这个组合思路很好用，建议结合自己的场景做取舍。

4.7 第七步：配置验证与固件共存

做完上面这些，重启设备，确认系统起来后根目录确实是overlay：

mount | grep overlay df -h /

如果输出显示overlay已经挂载在根上，并且可用空间与overlay分区相符，说明整个流程通了。再随便改一个文件，重启后看看是否还在：

echo "hello overlay" > /etc/test_persist reboot cat /etc/test_persist

能读到内容，说明持久化生效。

如果你用的是带固件自动升级机制的设备，还需要额外考虑overlay分区和固件升级的共存关系。很多升级流程会把整个系统分区重新写入，而不会动overlay分区的数据。这就带来一个好处：你的配置和第三方软件在升级后依然保留。但反过来，如果新固件的系统结构发生了变化，旧upper中的一些顶层目录可能不再匹配，导致系统行为异常。我的经验是，在做系统迁移或大版本升级前，先把overlay分区整体备份，同时设计一个“一键重置overlay”的开关，比如检测到某个标志文件就清空upper层。这样既能保留数据，又能快速回滚到干净状态。

5. 深入细节：overlayfs的copy-up、删除与更新模型

5.1 copy-up机制会不会让性能变差

很多人关心overlayfs会不会变慢，这个问题得分情况看。第一次打开一个只读文件并尝试写入时，内核会触发copy-up，把文件从lower层完整复制到upper层。这个复制动作会造成一次额外的读加写，大文件场景下确实会有明显的延时。但复制完成后，后续的读写都是在upper层的完整副本上直接进行，性能几乎与普通文件系统一致。

如果你有一个文件被频繁动态修改，比如数据库文件，它的性能表现取决于初始化时文件是否已经被复制到upper。如果它一直在lower层，每次启动后第一次写入都要经历一次全量复制。这也是为什么很多生产部署会在初始化脚本里，提前把这些常用文件“热”起来，用touch加一次写入触发copy-up，把复制动作挪到系统启动阶段完成，而不是等到业务尖峰时触发。

在开机自启脚本里加一句的示例：

for f in /etc/passwd /etc/shadow /etc/resolv.conf; do cat $f > /dev/null done

这并不算真正的copy-up，因为copy-up需要写操作触发。正确的做法是创建一个副本然后覆盖回去，或者直接对文件做一次mv加恢复。最稳妥的做法其实是干脆不干预，让系统自然copy-up，然后通过监控手段观察哪些路径经常出现延迟，再针对性地做优化。

5.2 文件删除：whiteout与重命名的底层逻辑

我在使用overlay过程中，遇到过一些诡异现象。比如删除上层文件之后，重启后文件又出现了。刚开始我很困惑，后来看了文档才明白：overlayfs的删除并不是真的从底层删掉文件，而是创建一种叫“whiteout”的标记。这个标记记录在upper层，告诉overlayfs“从这个视图里遮掉这个文件”。底层文件还在，只是不可见。

对使用者来说，这种设计是天衣无缝的：你看不到底层文件了，而且可以随便往同名路径写新文件。但一旦你把upper目录单独拿出来，挂载到另一个系统上，就能看到那些隐藏的文件和whiteout标记。这会导致一个常见问题：误把upper目录当成一个普通目录去打包、备份、迁移时，文件行为会跟你预期不符。

解决方案是备份时用tar的--xattrs保留trusted.overlay标记属性。不过更推荐的做法是：不要直接备份upper目录，而是通过最终merged视图来备份。这样你备份到的就是用户真正看到的数据，干净且还原时不需要处理各种overlay标记。

5.3 重命名和硬链接对上层目录的影响

overlayfs的重命名机制也有不少坑。当你重命名lower层的一个文件时，内核不会把原文件“搬”到upper层，而是会先copy-up，然后再改名。这就导致一个问题：如果你连续重命名一个大文件，每次重命名都会产生一次复制，“改名五分钟，复制跑半天”。我在处理一个几十GB的文件重命名时，第一次没意识到这个原因，以为机器卡死了，等了几分钟才完成。

硬链接的情况也需要注意。overlayfs在合并视图里看到的是一个硬链接，但如果其中某个链接被修改，copy-up会对所有链接生效，且链接关系不一定能在上层保留。跨目录的硬链接操作尤其容易失败。结论是，如果你的应用重度依赖硬链接，比如某些包管理器或容器仓库，提前测试一下在overlayfs上的行为再决定方案。

6. 常见问题与排查技巧实录

6.1 挂载失败：invalid argument

这是最常见的问题，没有之一。典型的报错是：

mount: mounting overlay on / failed: Invalid argument

排查方向按优先级来：

• 内核不支持overlayfs。先用cat /proc/filesystems | grep overlay确认。
• lower/upper/work的参数格式写错了。overlayfs对参数顺序不敏感，但要求每个目录都必须存在。尤其workdir目录不存在时，大概率就是这个报错。
• upper和work不在同一个文件系统。这个错会在启动时很明确地暴露出来，检查一下df的输出，确认两个目录在同一分区的同一次挂载下。
• 根目录下已经有别的服务打开了文件，导致overlay挂载时内核无法正确锁定视图。这种情况多见于手动在业务运行时挂载根目录，解决办法是在启动早期执行。

6.2 重启后又变回只读

如果你发现系统能正常跑，但重启后之前写的文件又没了，问题基本出在挂载时机上。可能你在用户态服务完全起来之后才执行挂载，又或者挂载脚本虽然启动了，但因为某个依赖没满足而静默退出。

排查方法：在挂载脚本里加日志和返回值检查。

echo "overlay-mount start" >> /var/log/overlay.log mount -t overlay overlay / -o ... >> /var/log/overlay.log 2>&1 echo "exit code: $?" >> /var/log/overlay.log

然后重启看日志，能定位到是哪一步出了问题。

还有一个隐蔽问题：如果你把rootfs写成了“启动时自动remount只读”，那么overlay挂载后根目录的mount option仍然可能是只读。其实overlay本身不继承底层挂载的ro/rw属性，但某些过于精简的内核或SDK会有异常行为。可以手动检查/proc/mounts，看看overlay的挂载参数里是否有ro标记。如果有，在挂载参数里补rw即可。

6.3 空间耗尽导致服务异常

overlay分区写满后，表现非常迷惑：有些服务还能正常启动，但无法写日志，系统又不报警；有些服务直接崩溃，提示磁盘空间不足。这里真正的问题是，df显示的/是overlay合并视图的总空间，它由upper层所在分区的剩余空间决定。当upper分区满时，你是没办法通过删除lower层的文件来释放空间的，因为lower层根本不可写，删除只会产生whiteout标记，且标记本身还要占用upper层空间。

我最开始没理解这点，遇到空间不足时尝试删/var/log/journal下的日志，结果不仅空间没释放，反而因为写入了大量whiteout标记占用更多空间。后来学乖了，遇到overlay分区满，正确做法是：

• 清理upper层里自己产生的文件，比如日志、临时文件、包缓存。
• 如果upper层结构复杂，用du逐层排查哪个目录占用最大。
• 对于日志这类增长型目录，设置logrotate并在overlay分区内自动清理，或者干脆把日志目录挂tmpfs。

6.4 copy-up失败与文件属主混乱

在某些情况下，触发copy-up时会出现Input/output error。这通常是因为底层文件系统或upper层文件系统出现坏块，尤其是NAND Flash和低质量SD卡上容易出现。另一个常见原因是底层文件被另一个进程以不一致方式访问，不过这个场景较少。

文件属主混乱的问题则多见于rootfs是squashfs、upper层是FAT分区这类组合。FAT不保存UNIX文件属主和权限位，导致所有文件看起来都是root或当前挂载用户的。这个问题的根治方案就是不用FAT做upper层，只用ext4或f2fs。如果你的电路板厂商给的SDK默认把upper分区格式化成vfat，趁早改掉。

6.5 长期运行后的“文件看不到”问题

overlayfs对目录项缓存和inode管理有自己的逻辑，在长期运行之后偶尔会出现目录列表不刷新、文件明明写入却看不到的情况。我碰到过的场景是：某些服务通过NFS或SMB共享overlay目录，客户端删除文件后，服务端仍然缓存着旧条目。其他客户端重新挂载后能看到，但原客户端看不到。

这种问题跟overlayfs本身关系不大，更多是缓存机制的问题。标准做法是重新挂载共享目录，或者设置合理的缓存时间。如果你用的是系统自带SMB服务，可以把sernet相关的缓存选项调低，问题基本能解决。

7. 进阶经验与优化方向

7.1 把日志和缓存放到tmpfs

overlay设计中最值得优化的一个点是，为了减少upper层的写入次数和空间消耗，尽量把系统运行时产生的高频写入文件重定向到内存文件系统。

我实际项目中就做了一个配置：

• /var/log挂tmpfs，日志按需保留。
• /var/tmp挂tmpfs，临时文件不落地。
• /root/.cache挂tmpfs，构建缓存不落盘。

这些目录在upper目录里只需要保留空目录即可，不用复制底层内容。挂载顺序要在overlay挂载之后，否则当你重新挂载/var/log时，过度的文件操作会触发大量copy-up。

mount -t tmpfs tmpfs /var/log

这样一个动作，不仅延长了闪存寿命，还大大降低了overlay分区被日志撑爆的概率。

7.2 处理固件升级场景下的overlay兼容

前面提过固件升级后overlay数据可能不兼容。这里再展开说下具体怎么处理。

我在一次项目中，设备固件升级后根文件系统的目录结构发生变化，新增了一个原来没有的/data目录。然而upper层中还保留着旧版本的顶层目录，虽然不影响基本使用，但新系统里的很多路径因为找不到lower层的对应层次，行为变得奇怪。排查了许久，最终确认是overlay把旧版本数据合入了新系统里。

解决方案是在升级脚本中加一个检查逻辑：检测新固件版本号变化时，自动备份原upper层到backup目录，然后重建一个干净的upper层。用户配置文件通过另设的独立配置文件分区保存，不同步到upper层。这样既保留了用户数据，又避免了overlay层次结构错乱。

7.3 overlay与容器技术的结合使用

如果你想更彻底地利用overlayfs，可以考虑把overlay分区与容器场景结合。嵌入式设备上跑Docker或Podman的场景越来越多，容器本身也依赖overlayfs分层镜像。这时候，宿主机的overlay分区可以同时作为容器的存储驱动底层。不过要注意，宿主rootfs的overlay和你给容器的overlay存储是两个不同的挂载层次，需要避免它们指向同一个upper目录。

一个合理布局是：

• 宿主根文件系统：overlay挂载，upper放在分区A。
• Docker数据目录：独立挂载点，存储驱动使用overlay2，数据放在分区B。

这样容器镜像层和宿主可写层完全隔离，删光容器数据不影响宿主系统配置，反之亦然。我在实际部署中体验很好，排查问题时思路也更清晰。

7.4 初始化配置与首启部署脚本的配合

最后分享一个提升项目落地性的细节。overlay分区的首次初始化，实际上是一个“一键恢复出厂设置”的天然切入点。我在脚本里增加了一个检测机制：如果upper目录的某个标志文件不存在，就执行一套初始化逻辑，比如创建默认配置、生成SSH主机密钥、设置默认WiFi。

FLAG=/mnt/overlay/upper/etc/.initialized if [ ! -f "$FLAG" ]; then echo "first boot after overlay created, initializing..." # 执行初始化 touch $FLAG fi

这样设备批量出厂时，可以统一用一个干净固件，第一次开机自动生成专属配置，运维负担小很多。这也是overlay方案在生产型设备上比“直接读写rootfs”更受青睐的一个重要原因。

实用命令速查表，供你日常操作参考：

附：一些实际操作后的个人建议

最后再唠叨几句。overlay分区的核心价值是把“系统”和“数据”彻底解耦，让它兼顾只读系统的安全性和可写系统的灵活性。但这也意味着你要接受两套数据模型并存的事实，不要把overlay简单理解成“让根目录可写”的小技巧，它更像是一整套设备存储方案的设计思路。

我这几轮项目做下来，最大的体会是：动手之前先把启动流程吃透，多花半小时梳理inittab和init脚本的执行顺序，比挂载失败后反复查日志要省力得多。另外，第一次实验别在带重要数据的设备上做，用一块廉价SD卡或临时eMMC试错，踩完所有坑再上生产环境，体验会完全不同。

如果你只是想让家里某台老设备“能存点东西”，这个方案半小时就能搭好；如果是为了产品量产时的远程维护和升级便利性，这套结构更是值得认真设计的。按照文中的步骤走一遍，再从你自己的实际场景出发做调整，会比拿现成脚本一把梭靠谱得多。