Linux OverlayFS详解

Linux OverlayFS详解OverlayFS是 Linux 内核自带的联合挂载Union Mount文件系统把多个目录叠成一个统一目录树读写在逻辑上像操作普通文件夹底层却可区分「只读基底」与「可写覆盖层」。Docker 镜像分层、Live 系统、测试回滚、增量备份背后常见都有它的影子。速览四要素lowerdir只读层upperdir读写层workdir内部工作目录→ 挂载到merged视图。读先upper再按优先级查lower。写修改 lower 上已有文件 →写时复制CoW到 upper 再改新建直接写在 upper。删 lower 文件在 upper 建whiteout标记不删 lower 实体。依赖upper/work 须在支持xattr的文件系统上如 ext4、xfs且同一文件系统。merged用户看到的统一视图 ↑ mount overlay lowerdir只读可多目录 upperdir可写 workdir临时目录一、概念与结构1. OverlayFS 是什么2. 四层目录角色二、读写与合并规则3. 读取路径4. 写入与写时复制 CoW5. 删除与 whiteout6. 目录合并与 opaque三、使用与场景7. 挂载命令与示例8. 典型应用场景9. 实战案例提要四、运维10. 性能与选型注意11. 速查卡1. OverlayFS 是什么特点说明联合挂载多个目录合并为一个逻辑文件系统视图非块设备 FS不直接管理磁盘块叠在ext4、xfs、btrfs 等已有 FS 之上内核原生Linux 3.18 主线容器生态广泛使用与 UnionFS思路相近现代 Linux 上OverlayFS是主流实现底层文件系统Overlay 层用户视角merged 挂载点统一目录树upperdir 可写lowerdir 只读可多层workdir 内部ext4 / xfs / …2. 四层目录角色目录别名读写作用lowerdir下层 / 只读层只读基底内容可多个逗号分隔左侧优先级高于右侧upperdir上层 / 读写层读写所有变更新建、修改、删除标记落在这里workdir工作目录内核用必须为空CoW 等操作的临时空间必须与 upperdir 同一文件系统merged合并视图 / 挂载点用户访问mount后对外呈现的路径lowerdirA:B:C 只读查找时 **A 优先于 B 优先于 C**最左优先级最高 upperdirU 唯一可写 workdirW 空目录与 U 同 FS mergedM mount 目标Docker 对应关系概念OverlayDockerlowerdir 多层镜像层只读upperdir容器可写层merged容器内/所见根文件系统3. 读取路径是文件/目录否是否访问 merged 下路径upperdir存在?返回 upper 内容按优先级扫描 lowerdir左 → 右找到?返回 lower 内容不存在规则说明文件upper 有则用 upper否则在 lower 链中找第一个命中目录同名目录合并展示见 §6whiteoutupper 上的特殊标记表示「下层文件已删除」读时不可见4. 写入与写时复制 CoW操作行为在 merged 新建文件/目录直接创建在upperdir修改 upper 已有文件直接写 upper修改 lower 已有文件CoW先复制到 upper再改 upper 副本lower 原文件不变workdirupperdirlowerdirmerged应用workdirupperdirlowerdirmerged应用lower 中 foo 不变写 lower 已有文件 fooCoW: 复制 foo 到 upper用 workdir 辅助修改 upper/fooCoW 的价值多实例共享只读 lower如镜像层→省磁盘容器秒级启动不必复制整镜像回滚测试环境 →删掉 upper即可恢复 lower 视图。代价首次修改大文件时有一次完整复制I/O频繁改大量小文件时元数据与 CoW 压力上升见 §10。5. 删除与 whiteout删除对象实际行为upper 中的文件直接从 upper删除仅存在于 lower 的文件在 upper 创建whiteout特殊字符设备或 xattr 标记merged 视图中该路径消失lower 实体仍保留目录规则类似可能配合opaque§6lower: /bin/app 只读镜像里 用户: rm merged/bin/app upper: 出现 whiteout 标记不是真删 lower merged: /bin/app 不可见whiteout让「逻辑删除」与「物理只读层」共存是镜像分层的基础机制之一。6. 目录合并与 opaque6.1 目录合并上下层同名目录在 merged 中合并列出upper 与 lower 中的条目一起呈现子项仍遵循「文件优先 upper、否则 lower」。lower/foo: a.txt b.txt upper/foo: c.txt merged/foo: a.txt b.txt c.txt 合并视图6.2 opaque 目录若在upper某目录设置opaque属性依赖 xattrmerged 中该目录不再合并lower 同名目录内容表现为 upper 目录完全遮蔽lower 侧同名树。用于「上层整棵替换下层子树」的语义。7. 挂载命令与示例7.1 基本语法mount-toverlay overlay\-olowerdirlower[,lower2...],upperdirupper,workdirwork\mountpoint选项含义lowerdir一个或多个只读目录逗号分隔左优先upperdir可写层workdir空目录与 upper 同 FSmountpointmerged 挂载点需已存在7.2 最小实验mkdir-p/tmp/ovl/{lower,upper,work,merged}echofrom lower/tmp/ovl/lower/hello.txtmount-toverlay overlay\-olowerdir/tmp/ovl/lower,upperdir/tmp/ovl/upper,workdir/tmp/ovl/work\/tmp/ovl/mergedcat/tmp/ovl/merged/hello.txt# from lowerechofrom upper/tmp/ovl/merged/new.txtls/tmp/ovl/upper/new.txt# 新文件只在 upperechomodified/tmp/ovl/merged/hello.txt# CoW 后 upper/hello.txt 存在lower/hello.txt 仍为 from lowerumount/tmp/ovl/merged7.3 多层 lowermount-toverlay overlay\-olowerdir/layer2:/layer1,upperdir/upper,workdir/work\/mergedlayer2中同名文件优先于layer1。7.4 常用挂载参数选读参数说明indexon/off是否用索引优化硬链接等部分场景indexoff降开销xinoon跨层 inode 编号展示调试/兼容redirect_diron目录重命名优化较新内核具体以当前内核Documentation/filesystems/overlayfs.txt为准。8. 典型应用场景场景lowerupper收益Docker / K8s 容器镜像层只读容器层共享镜像、隔离可写、快速创建Live CD / 只读根系统只读分区U 盘或缓存分区系统完整性 会话内可写软件测试 / 升级稳定系统快照测试 upper失败则删 upper 回滚增量备份全量备份目录当日变更 upper只备份 upper ≈ 增量增量备份全量 lower每日 upper容器镜像层 lower容器 A upper容器 B upper9. 实战案例提要9.1 Docker 分层镜像各层只读叠加为lower 链docker run创建容器可写层 upper容器内echo、apt install写入 upper删除容器常删除 upper 层数据。查看宿主机路径因存储驱动而异dockerinspectcontainer--format{{.GraphDriver.Data}}# overlay2: LowerDir, UpperDir, WorkDir, MergedDir9.2 Live USB系统镜像作 lower用户数据分区作 upper 或独立挂载重启后保留 upper 中 home 等变更需正确分区与挂载脚本。9.3 测试与升级回滚lower 当前稳定根文件系统快照只读挂载 upper /test-upper merged 挂载后在此 chroot 或容器内测试 测试失败: umount merged rm -rf /test-upper/*9.4 增量备份与恢复1. 全量 rsync → /backup/base 作 lower 2. 每日变更 overlay upperdir/backup/inc-20260526 3. 备份任务只同步 upper 增量体积小 4. 恢复: overlay 挂载 base 各日 upper 或合并策略还原视图具体脚本因备份产品而异核心是lower 稳定 upper 存差量。10. 性能与选型注意注意项说明CoW 开销首次改大文件复制整文件海量小文件频繁写 → IOPS 与延迟敏感upper 文件系统需xattropaque、部分 whiteout推荐ext4、xfsworkdir必须空目录与upperdir 同一文件系统优化思路测试环境 upper 用tmpfs评估indexoff避免在 overlay 上再叠复杂 FS权限与 SELinux容器场景注意挂载标签、--security-optupper 权限需与进程匹配NFS 作 upper可行但 xattr/锁语义需验证生产常本机块设备更稳现象可能原因mount 失败 invalid argumentworkdir 非空、upper/work 不同 FS、lower 路径不存在修改不生效写的是 lower 只读挂载点而非 merged空间暴涨CoW 复制大文件 upper 累积未清理11. 速查卡┌─────────────────────────────────────────────────────────┐ │ 读: upper → lower左优先 │ │ 写: 新文件→upper改 lower 文件→CoW 到 upper 再改 │ │ 删: upper 文件直接删lower 文件→upper whiteout │ │ 目录: 合并upper opaque → 屏蔽 lower 同名树 │ ├─────────────────────────────────────────────────────────┤ │ mount -t overlay overlay -o lowerdir,upperdir,workdir │ │ workdir: 空与 upper 同 FSupper 需 xattr(ext4/xfs) │ ├─────────────────────────────────────────────────────────┤ │ Docker: 镜像lower 链 容器层upper 视图merged │ └─────────────────────────────────────────────────────────┘落地注意生产容器多通过overlay2存储驱动使用 OverlayFS路径与手工mount示例不同但lower/upper/work/merged 语义一致。内核与 util-linux 版本差异会导致挂载选项略有不同部署前在目标环境做一次mount 实验。嵌入式/Android 等场景若涉及只读 system 可写 data需结合dm-verity、AVB等安全机制不能仅靠 Overlay 理解全盘方案。一句话OverlayFS用只读 lower 可写 upper叠出统一视图靠CoW 与 whiteout实现省空间、快启动、易回滚——搞懂四层目录与读写规则就抓住了 Docker 分层与大量「基底 差量」系统设计的底层逻辑。