【docker】overlay2文件系统

• AUFS： 原生支持 多个只读分支（层）。

• 早期 OverlayFS (Overlay)： 原生只支持一个只读层 (lowerdir)。需要多层只读时，必须通过嵌套挂载实现，较为繁琐。

• Overlay2 (现代 OverlayFS)： 原生支持多个只读层 (lowerdir) (最多 128 层)，与 AUFS 在多层支持能力上达到同等水平，且实现方式更直接高效

workdir作用

场景 1: 新建文件（不需要 workdir）

• ➕ 新建 file4：直接写入 upperlayer/file4

• ✅ 操作简单，无需 workdir

场景 2: 修改文件（不需要 workdir）

• ✏️ 修改 file3 (来自 layer2):

  1. 先将 layer2/file3 复制到 upperlayer/file3 (Copy-on-Write)

  2. 修改 upperlayer/file3

• ✅ 直接在 upperlayer 完成

场景 3: 删除文件（需要 workdir 协作）

• ❌ 删除 file2 (来自 layer1):

  1. OverlayFS 在 upperlayer 创建 whiteout 文件：.wh.file2

  2. workdir 角色：在删除过程中临时处理元数据锁定，确保操作原子性

  3. 结果：file2 在挂载点"消失"

场景 4: 重命名文件（严重依赖 workdir）

• 🔄 将 file1 重命名为 file1_new：

  1. 复杂性来源：

     • file1 实际数据在 layer2（因为 layer2 覆盖了 layer1）

     • 重命名需要跨层操作

  2. workdir 的关键作用：

     • 在 workdir 创建临时副本（避免损坏原始数据）

     • 原子性操作步骤：

     • 最终结果：

       • upperlayer 出现 file1_new（新文件）

       • upperlayer 出现 .wh.file1（标记删除原只读文件）

为什么一定要使用workdir？

1. 原子性保证 (Atomicity)
   重命名/删除操作必须"完全成功"或"完全失败"，不能出现中间状态。workdir 提供安全沙盒完成多步操作。

2. 避免数据损坏
   直接操作 upperlayer 可能因断电/崩溃导致：

   • 新文件写入一半

   • 旧文件已删但新文件未就绪，workdir 作为缓冲降低风险。

3. 遵守 POSIX 语义
   文件系统必须满足 rename() 系统调用的原子性要求，workdir 是实现此承诺的基础设施。

4. 性能优化
   虽然多了一次临时复制，但避免了全局文件锁，提升了并发性能。

workdir 是 OverlayFS 为保证复杂文件操作的安全性和一致性而设计的临时工作区，尽管用户数据始终只存在于 upperlayer 和只读层中。

OverlayFS 的创新不是要改变“有一个可写层”这个联合文件系统的基本模式，而是要创建一个更符合内核标准、更简单高效、更可持续且最终功能完备的替代方案，以解决 AUFS 的历史遗留问题。