Linux Overlay的存储管理

Linux Overlay 存储管理要点

一 核心概念与数据结构

• 组成要素：一个只读的lowerdir（可包含多层，以“:”分隔、从左到右优先级递减）、一个可写的upperdir、一个同属 upper 所在文件系统的workdir（内核工作区，必须为空）、对外统一视图的merged。删除文件并非真正删除下层数据，而是在 upper 生成whiteout（字符设备 0/0）标记；删除目录则通过给 upper 目录设置扩展属性trusted.overlay.opaque=y形成不透明目录来屏蔽下层同名目录。OverlayFS 支持多 lower，但“挂载时”呈现为两层语义：upper + 合并后的 lower 集合。读时优先 upper，找不到再按 lower 顺序查找；写时触发copy_up（按需复制，首次修改才发生）。这些机制共同保证了“下层不变、上层可变”的联合视图与一致性。

二 读写删除与空间占用机制

• 读取：若文件仅在 lower，直接从 lower 读；若仅在 upper，从 upper 读；同名时以 upper 为准（lower 被隐藏）。目录则进行合并浏览。
• 写入：对 lower 中文件进行写/改元数据/创建硬链接等，会先执行copy_up到 upper，再在 upper 上修改；后续操作都在 upper 完成。注意：创建硬链接也会触发 copy_up，因为需要为 upper 创建新 inode；而创建符号链接不需要。
• 删除：删除 lower 中的文件时，在 upper 生成whiteout以屏蔽之；删除目录时，在 upper 创建opaque 目录以屏蔽下层同名目录。被屏蔽的下层对象并未被物理删除，只有清空 upper（或删除对应 whiteout/opaque 标记）后才会再次显现。
• 空间影响：所有写入与“新增”都落在upperdir，因此 upper 的容量直接决定可写空间；lower 的变更（尤其离线）不影响已挂载的 overlay 视图，但底层变更与上层叠加的行为未定义，应避免在线改动下层。
• 内存与缓存：多个容器/进程访问同一只读文件可共享页缓存，有利于降低内存占用；但 copy_up 后的文件成为 upper 的新 inode，其属性（如 st_dev/st_ino）可能与下层不同，个别依赖 inode 稳定性的工具需注意。

三 在容器与发行版中的落地实践

• Docker 存储驱动：优先选用overlay2而非 overlay，因其在inode 利用率上更高效。内核要求：Linux 4.0+，或 RHEL/CentOS 3.10.0-514+。底层文件系统为 XFS 时必须启用 d_type=true（ftype=1），可用 xfs_info 检查；在不支持 d_type 的 XFS 上，Docker 会跳过使用 overlay/overlay2。变更存储驱动会使本地容器/镜像不可访问，操作前应先 docker save/push 备份。
• 手工挂载示例：

  mkdir -p /mnt/overlay/{
  lower,upper,work,merged}
      
  mount -t overlay overlay \
    -o lowerdir=/mnt/overlay/lower,\
        upperdir=/mnt/overlay/upper,\
        workdir=/mnt/overlay/work \
    /mnt/overlay/merged
  

  验证：df -h /mnt/overlay/merged；卸载：umount /mnt/overlay/merged。
• 嵌入式 OpenWrt 的典型形态：只读固件层 /rom（常见为 SquashFS）+ 可写层 /overlay/upper，启动时由 OverlayFS 合并为 /；配置更改、软件安装都写入 upper。执行 firstboot 或清空 /overlay/upper 相当于“恢复出厂设置”。这类场景的可用空间完全取决于 overlay 分区大小。

四 容量规划与问题排查

• 容量规划与瓶颈：
  • 可写空间=upperdir 所在分区的可用空间；大文件“首次修改”会触发 copy_up，可能导致短时空间激增与 I/O 峰值。
  • 大量小文件/高 churn 场景会快速消耗inode（尤其在早期 overlay 实现中），overlay2 已显著优化；如仍受限，可将 /var/lib/docker（或 upper 所在路径）单独挂到更大且 inode 充足的文件系统。
• 常用检查与定位：
  • 查看挂载与层信息：mount | grep overlay；docker info | grep -i storage；lsblk/df -h；必要时 xfs_info 检查 ftype。
  • 识别“被屏蔽”的对象：在 upper 查找 .wh. whiteout* 文件与带有 trusted.overlay.opaque=y 的目录，确认是否因删除/覆盖导致下层不可见。
  • 避免在线改动下层：不要在 overlay 挂载期间修改 lower 的底层内容，行为未定义且易引发一致性问题。
• 场景化建议：
  • 容器工作负载：优先使用 overlay2；确保底层 XFS ftype=1；监控 upper 空间与 inode；对大文件随机写较多的负载，评估 copy_up 带来的写放大与延迟影响。
  • 嵌入式/只读根：合理规划 /overlay 分区大小；空间不足时通过迁移/扩容 overlay 分区或使用 extroot 等方案扩展持久化存储。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！