在嵌入式设备（如 OpenWrt 路由器、机顶盒、IoT 设备）以及现代容器技术（如 Docker）中，OverlayFS 几乎是一个不可或缺的标配技术。它凭借极简的设计和优秀的性能，将“只读”与“可写”完美融合，既保护了底层固件不被破坏，又赋予了用户自由修改数据的能力。

本文将从 OverlayFS 的核心概念、发展历史出发，并结合 2026 年 Linux 存储、文件系统、内存管理和 BPF 峰会（Linux Storage, Filesystem, Memory Management, and BPF Summit）上的最新技术演进，带你全面了解这个现代 Linux 基石的过去、现在与未来。

一、 什么是 OverlayFS？

OverlayFS 是一种联合文件系统（Union Filesystem），它提供了一种将多个其他文件系统融合在一起、从而创建单个挂载文件系统的方法。

它呈现了这些文件系统中文件的联合视图（union）。底层文件系统是有先后顺序的，上层文件系统中的条目会优先于下层文件系统中同名的文件和目录。通常情况下，最上层是可写的（Upper layer），而下层是只读的（Lower layer）。这样用户就可以直接修改挂载后的融合目录（Merged view）中的文件，而不会实际改变底层文件系统。

二、 OverlayFS 的前世今生

从一个边缘补丁走向工业标准，OverlayFS 的发展史可以说是一曲长达多年的“合并拉锯战”。

1. 百家争鸣的“史前时代”（2000s - 2010）

在 OverlayFS 出现之前，Linux 社区对联合文件系统的需求就已经非常迫切。当时主要有两大流派：UnionFS（代码复杂、经常导致内核崩溃）和 AUFS（性能较好，Docker 早期默认采用，但代码量过于庞大晦涩，多次被 Linus Torvalds 拒绝并入主线）。当时由于没有官方内置功能，早期的嵌入式 Linux 只能依靠不稳定的外置补丁。

2. 诞生与漫长的代码审查（2010 - 2014）

为了彻底解决这一痛点，匈牙利工程师 Miklos Szeredi（FUSE 框架的作者）在 2010 年左右提出了 OverlayFS。与前辈相比，它走了一条极简主义路线：不尝试在内核中实现复杂的虚拟文件系统，而是直接利用 Linux 现有的 VFS（虚拟文件系统）层和底层文件系统（如 ext4、XFS）的特性。经历了长达 4 年、十多个版本的修改与激烈辩论后，它终于在 2014 年底发布的 Linux 3.18 内核中被正式合并到主线。

3. 功能完善与多层支持（2017 - 2021）

并入主线后，OverlayFS 迅速成为 Docker（overlay2 存储驱动）和 OpenWrt 的核心基石。随着云原生爆发，原本“只有两层”的设计开始不够用了：

• Linux 4.13 (2017年)：引入了多低层（Multiple lower layers）支持，奠定了现代容器分层镜像的基础。

• Metacopy 特性：引入了只复制元数据（如权限、所有者）而不复制文件内容的机制，极大提高了大文件修改属性时的性能。

三、 2026 年峰会前沿：OverlayFS 最新技术演进

在 2026 年 Linux 存储、文件系统、内存管理和 BPF 峰会的一个简短会议中，Amir Goldstein 带来了关于 OverlayFS 的最新进展。

Goldstein 在开场时提到，Miklos Szeredi 曾谈到过一个“当 overlayfs 完工时”的时间点，这让他想起了“历史的终结”这一概念。“那么，自‘历史终结’以来都发生了什么呢？” Goldstein 微笑着问道。事实上，技术的发展带来了更多全新的挑战。

1. 引入 Composefs 支持与数据层分离

为了支持 composefs（其 file contents 以内容寻址对象的形式存储，并使用 fs-verity 进行完整性保护），overlayfs 引入了一些新概念：

• 仅数据低层（data-only lower layers）：这些层缺少元数据，类似于现有的 metacopy 特性，但它允许使用 fs-verity 来验证 inode 元数据与其内容之间的连接。

2. 全新的挂载 API 与凭据分离

Christian Brauner 已将 overlayfs 切换到使用全新的挂载 API（mount API），这消除了诸如低层数量限制以及路径名长度限制等硬性制约。

Brauner 还介绍了另一项改进：分离挂载层所需的凭据（credentials）与挂载后访问该层所需的凭据。例如，挂载者可能需要与访问该挂载的任务不同的 SELinux 上下文。对于 overlayfs 而言，它允许管理员指定用于通过挂载文件系统访问该层的凭据。

以前，overlayfs 只有一套凭据，对应于执行文件系统挂载的任务。它使用这些凭据来访问低层，而不是使用在挂载的 overlayfs 上执行文件系统操作的用户的凭据。现在，挂载文件系统时使用的凭据可以与访问时使用的凭据隔离开来。

“我们的安全模型有一个好迹象，那就是我们需要两个不同的人来提供两种不同的解释，” Brauner 笑着说。

“而且这两种解释都没人能听懂，” Goldstein 补充道，引发了全场大笑。

四、 嵌套 OverlayFS 的挑战与未来

OverlayFS 可以被嵌套，这意味着构成 overlayfs 文件系统的其中一层本身也是一个 overlayfs 文件系统。这一功能其实已经实现了十多年。

• 经典示例：创建一个包含两个 XFS 层的 overlayfs 并将其作为低层；然后将另一个文件系统作为上层，最终融合成一个将第一个 overlayfs 作为其低层的 overlayfs。这在容器或 OpenWrt 中很常见，因为用户希望在不破坏只读根 overlayfs 的基础上对其进行修改。

然而，目前所有的嵌套类型都只允许将 overlayfs 作为低层，而不能作为上层。

1. 突破 Docker “容器套容器”的限制

最近出现的一个新用例是在一个根文件系统已经是 overlayfs 的容器内运行 Docker 应用程序。Docker 会尝试使用现有的根文件系统作为上层来创建 overlayfs，但目前 overlayfs 无法作为上层。因此，Docker 只能退而求其次，使用“朴素存储驱动（naive storage driver）”解压其镜像，这需要将所有文件复制到一个扁平的文件系统中，耗费了大量的时间和 I/O。

如果能扩展 overlayfs，使其也能将另一个 overlayfs 用作上层，那就再好不过了。“那将是嵌套 overlayfs 历史的终结，” 他笑着说。

2. 栈深度与层合并的讨论

Brauner 询问是否允许将多个本身是 overlayfs 的低层组合起来，但 Goldstein 不确定这是否有实际的用例。目前，内核为了防止栈溢出（stack-depth concerns）限制了嵌套层数。

Brauner 提出，与其嵌套，不如将它们折叠合并（collapse）。OverlayFS 可以收集访问不同层所需的凭据，但实际上将它们视为单层处理，从而绕过嵌套限制。

五、 镜像更新、系统自省与白出（Whiteout）机制

1. 基于镜像的更新与 systemd

Brauner 表示，现在整个行业正在转向基于镜像的更新（image-based updates）。systemd 通过引入一个只读的 /usr 来支持这一点，并在其上添加多个系统扩展（sysext）层，所有这些层都被融合到一个 overlayfs 中。随着时间的推移，sysext 层会越来越多，因此 systemd 必须定期重新组装 overlayfs。如果能直接对 overlayfs 进行自省操作会方便得多。

Lennart Poettering 提到，systemd 开发者非常希望能有某种工具来查看构成 /usr 挂载点的不同层。这将允许他们通过密码学手段，将文件追溯到其在受 fs-verity 保护的数据中的源头。Goldstein 回应称，提供某种自省 API（introspection API）在技术上是完全可行的。

2. 冲突解决与恢复被删除的文件

Ted Ts'o 询问，当前描述的用例是否类似于在基于 overlayfs 的分层安装中进行发行版更新：用户修改了一个配置文件，而该文件现在需要更新，从而导致冲突。Brauner 回应称这是一个完全不同的用例，在这个用例中，/usr 和 /etc 理想情况下都是只读的，如果还需要让用户做 diff 选择，“你就已经把事情搞砸了”。

对于 /etc 的情况，一位与会者提到，顶层是可写的，以便用户修改配置。有时用户想删除他们的更改并恢复到低层中的版本，但删除文件会导致产生一个白出文件（whiteout，用于隐藏下层文件的特殊标记）。他希望能有一种方法来重新显现（reveal）底层文件，而不是用白出标记阻止它。

Brauner 询问他是希望在单个文件级别还是在整个文件系统级别实现。前者需要系统调用级别的更改，可能会更困难。Goldstein 则问，关于要显现的文件已知哪些信息？如果是文件句柄（file handle），可能会更有用，因为 overlayfs 中已经有防止利用文件句柄规避白出标记的保护机制，在某些情况下或许可以绕过这些保护。David Howells 对嵌套 overlayfs 以及如何识别应该复活哪个文件表示担忧，但 Goldstein 表示 overlayfs 的文件句柄确实同时描述了这两个层，因此是可以使用的。

“不过，我对此不作任何承诺，” Goldstein 说道。随后，该会议由于时间耗尽而结束。