在嵌入式设备如 OpenWrt 路由器、机顶盒、IoT 设备以及现代容器技术如 Docker中OverlayFS几乎是一个不可或缺的标配技术。它凭借极简的设计和优秀的性能将“只读”与“可写”完美融合既保护了底层固件不被破坏又赋予了用户自由修改数据的能力。本文将从 OverlayFS 的核心概念、发展历史出发并结合 2026 年 Linux 存储、文件系统、内存管理和 BPF 峰会Linux Storage, Filesystem, Memory Management, and BPF Summit上的最新技术演进带你全面了解这个现代 Linux 基石的过去、现在与未来。一、 什么是 OverlayFSOverlayFS是一种联合文件系统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 SzerediFUSE 框架的作者在 2010 年左右提出了 OverlayFS。与前辈相比它走了一条极简主义路线不尝试在内核中实现复杂的虚拟文件系统而是直接利用 Linux 现有的 VFS虚拟文件系统层和底层文件系统如 ext4、XFS的特性。经历了长达 4 年、十多个版本的修改与激烈辩论后它终于在 2014 年底发布的Linux 3.18内核中被正式合并到主线。3. 功能完善与多层支持2017 - 2021并入主线后OverlayFS 迅速成为 Dockeroverlay2存储驱动和 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 切换到使用全新的挂载 APImount 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. 基于镜像的更新与 systemdBrauner 表示现在整个行业正在转向基于镜像的更新image-based updates。systemd通过引入一个只读的/usr来支持这一点并在其上添加多个系统扩展sysext层所有这些层都被融合到一个 overlayfs 中。随着时间的推移sysext 层会越来越多因此 systemd 必须定期重新组装 overlayfs。如果能直接对 overlayfs 进行自省操作会方便得多。Lennart Poettering 提到systemd 开发者非常希望能有某种工具来查看构成/usr挂载点的不同层。这将允许他们通过密码学手段将文件追溯到其在受 fs-verity 保护的数据中的源头。Goldstein 回应称提供某种自省 APIintrospection API在技术上是完全可行的。2. 冲突解决与恢复被删除的文件Ted Tso 询问当前描述的用例是否类似于在基于 overlayfs 的分层安装中进行发行版更新用户修改了一个配置文件而该文件现在需要更新从而导致冲突。Brauner 回应称这是一个完全不同的用例在这个用例中/usr和/etc理想情况下都是只读的如果还需要让用户做 diff 选择“你就已经把事情搞砸了”。对于/etc的情况一位与会者提到顶层是可写的以便用户修改配置。有时用户想删除他们的更改并恢复到低层中的版本但删除文件会导致产生一个白出文件whiteout用于隐藏下层文件的特殊标记。他希望能有一种方法来重新显现reveal底层文件而不是用白出标记阻止它。Brauner 询问他是希望在单个文件级别还是在整个文件系统级别实现。前者需要系统调用级别的更改可能会更困难。Goldstein 则问关于要显现的文件已知哪些信息如果是文件句柄file handle可能会更有用因为 overlayfs 中已经有防止利用文件句柄规避白出标记的保护机制在某些情况下或许可以绕过这些保护。David Howells 对嵌套 overlayfs 以及如何识别应该复活哪个文件表示担忧但 Goldstein 表示 overlayfs 的文件句柄确实同时描述了这两个层因此是可以使用的。“不过我对此不作任何承诺” Goldstein 说道。随后该会议由于时间耗尽而结束。
融合之美：Linux OverlayFS 联合文件系统的演进与前沿
发布时间：2026/7/10 10:32:36
在嵌入式设备如 OpenWrt 路由器、机顶盒、IoT 设备以及现代容器技术如 Docker中OverlayFS几乎是一个不可或缺的标配技术。它凭借极简的设计和优秀的性能将“只读”与“可写”完美融合既保护了底层固件不被破坏又赋予了用户自由修改数据的能力。本文将从 OverlayFS 的核心概念、发展历史出发并结合 2026 年 Linux 存储、文件系统、内存管理和 BPF 峰会Linux Storage, Filesystem, Memory Management, and BPF Summit上的最新技术演进带你全面了解这个现代 Linux 基石的过去、现在与未来。一、 什么是 OverlayFSOverlayFS是一种联合文件系统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 SzerediFUSE 框架的作者在 2010 年左右提出了 OverlayFS。与前辈相比它走了一条极简主义路线不尝试在内核中实现复杂的虚拟文件系统而是直接利用 Linux 现有的 VFS虚拟文件系统层和底层文件系统如 ext4、XFS的特性。经历了长达 4 年、十多个版本的修改与激烈辩论后它终于在 2014 年底发布的Linux 3.18内核中被正式合并到主线。3. 功能完善与多层支持2017 - 2021并入主线后OverlayFS 迅速成为 Dockeroverlay2存储驱动和 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 切换到使用全新的挂载 APImount 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. 基于镜像的更新与 systemdBrauner 表示现在整个行业正在转向基于镜像的更新image-based updates。systemd通过引入一个只读的/usr来支持这一点并在其上添加多个系统扩展sysext层所有这些层都被融合到一个 overlayfs 中。随着时间的推移sysext 层会越来越多因此 systemd 必须定期重新组装 overlayfs。如果能直接对 overlayfs 进行自省操作会方便得多。Lennart Poettering 提到systemd 开发者非常希望能有某种工具来查看构成/usr挂载点的不同层。这将允许他们通过密码学手段将文件追溯到其在受 fs-verity 保护的数据中的源头。Goldstein 回应称提供某种自省 APIintrospection API在技术上是完全可行的。2. 冲突解决与恢复被删除的文件Ted Tso 询问当前描述的用例是否类似于在基于 overlayfs 的分层安装中进行发行版更新用户修改了一个配置文件而该文件现在需要更新从而导致冲突。Brauner 回应称这是一个完全不同的用例在这个用例中/usr和/etc理想情况下都是只读的如果还需要让用户做 diff 选择“你就已经把事情搞砸了”。对于/etc的情况一位与会者提到顶层是可写的以便用户修改配置。有时用户想删除他们的更改并恢复到低层中的版本但删除文件会导致产生一个白出文件whiteout用于隐藏下层文件的特殊标记。他希望能有一种方法来重新显现reveal底层文件而不是用白出标记阻止它。Brauner 询问他是希望在单个文件级别还是在整个文件系统级别实现。前者需要系统调用级别的更改可能会更困难。Goldstein 则问关于要显现的文件已知哪些信息如果是文件句柄file handle可能会更有用因为 overlayfs 中已经有防止利用文件句柄规避白出标记的保护机制在某些情况下或许可以绕过这些保护。David Howells 对嵌套 overlayfs 以及如何识别应该复活哪个文件表示担忧但 Goldstein 表示 overlayfs 的文件句柄确实同时描述了这两个层因此是可以使用的。“不过我对此不作任何承诺” Goldstein 说道。随后该会议由于时间耗尽而结束。
)
