1 overlay2分层介绍

OverlayFS 是一个联合文件系统。

对内核的需求

• Linux 内核 4.0 或更高版本
• 或使用3.10.0-514 或更高版本内核的 RHEL 或 CentOS。

更改存储驱动程序会导致本地系统上现有的容器和镜像无法访问。在更改存储驱动程序之前，需要使用 docker save保存已构建的所有镜像，或将其推送到 Docker Hub 或私有镜像仓库，这样以后就无需重新创建它们。

通过docker info可以查看目前docker使用的存储驱动

2 overlay2工作原理

OverlayFS（叠加文件系统）将Linux主机上的两个目录进行分层，并将其呈现为一个统一的目录。这些目录被称为"层"（layers），而统一过程则称为"联合挂载"（union mount）。OverlayFS将下层目录称为"lowerdir"，即镜像内的只读层，上层目录称为"upperdir"，即创建容器后的可读可写层。最终通过名为"merged"（合并层）的独立目录展示统一后的视图。

在merged目录可以看到容器内所有层的文件信息

下面通过一个表格简述各层之间的关系

启动容器后，可以通过mount命令查看到容器的overlay2挂载信息

其中lowerdir共有三个目录，对应镜像中的不同层

查看容器对应的数据目录

docker inspect 9c9b5fdb76e2 --format '
UpperDir:  {{.GraphDriver.Data.UpperDir}}
LowerDir:  {{.GraphDriver.Data.LowerDir}}
MergedDir: {{.GraphDriver.Data.MergedDir}}
WorkDir:   {{.GraphDriver.Data.WorkDir}}'

3 overlay2层数限制

Overlay2存储驱动原生支持最多128个下层OverlayFS镜像层。该特性为Docker层相关操作（如docker build构建镜像和docker commit提交变更）提供了更优异的性能表现，同时能有效减少底层文件系统的inode占用。

(1) 128 层的来源

• OverlayFS 内核实现中，lowerdir 参数最多支持 128 个路径（以 : 分隔）。
• 每个 Docker 镜像层（RUN、COPY 等指令生成的层）对应一个 OverlayFS 的 lowerdir。

(2) 层合并示例

假设一个镜像有 3 个层：

FROM ubuntu            # 层1
RUN apt update         # 层2
COPY app /app          # 层3

挂载时：

lowerdir=层3:层2:层1  # 从顶层到底层依次排列

(3) 超出 128 层的处理

• 若镜像层数超过 128，Docker 会自动合并部分层（通过 flatten 操作），但会牺牲部分效率。
• 最佳实践：通过多阶段构建或合并指令（如 &&）减少层数。

4 磁盘上的容器和镜像层

下图展示了Docker镜像与容器的分层结构。镜像层作为lowerdir（下层目录），容器层作为upperdir（上层目录）。当镜像存在多个分层时，系统会使用多个lowerdir目录。最终通过名为merged（合并层）的目录呈现统一视图，该目录实质上就是容器的挂载点（容器内的根目录）。

当镜像层与容器层存在相同文件时，容器层（upperdir/上层目录）的文件将优先生效，并遮蔽镜像层中的同名文件。

overlay2驱动在创建容器时，会将代表镜像顶层的目录与新建的容器目录进行联合挂载。镜像各层作为overlay的lowerdir（下层目录）处于只读状态，而新建的容器目录则作为upperdir（上层目录）可写入。

5 在overlay2下容器读写机制

5.1 读取文件

场景一：文件仅存在于镜像层（lowerdir）

当容器尝试读取某个文件时，若该文件不存在于容器层（upperdir），系统会直接从镜像层（lowerdir）读取。此操作产生的性能开销极低。

场景二：文件仅存在于容器层（upperdir）

当容器读取的文件仅存在于容器层（upperdir）而镜像层（lowerdir）中不存在时，系统将直接从容器层读取文件内容。

场景三：文件同时存在于容器层和镜像层

若文件同时存在于容器层（upperdir）和镜像层（lowerdir），系统会优先读取容器层中的文件版本。容器层中的文件始终会遮蔽（override）镜像层中的同名文件。

5.2 修改文件或目录

5.2.1 首次写入文件时处理逻辑

当容器首次对某个已存在的文件执行写操作时（该文件尚未存在于容器层/upperdir），overlay2驱动将执行copy_up操作，把文件从镜像层（lowerdir）完整复制到容器层（upperdir），后续所有修改将作用于容器层中的文件副本。

需特别注意：

• OverlayFS基于文件层面而非块级别运作，即使仅修改大文件的一小部分，copy_up操作仍会复制整个文件，这可能显著影响容器写入性能
• copy_up操作仅在该文件首次被修改时触发，后续写入直接作用于容器层中的副本文件
• 多层镜像结构可能导致文件检索性能下降，尤其当镜像层数较多时

(1) 文件检索的底层机制

当容器访问一个文件（如 /usr/bin/python3）时，OverlayFS 会按以下顺序查找：

• 从顶层开始向下搜索upperdir（容器可写层）→ 第一层 lowerdir → 第二层 lowerdir → ... → 最底层 lowerdir
• 首次匹配即返回一旦在某层找到文件，立即终止搜索（类似 PATH 环境变量的查找逻辑）

(2) 性能下降的核心原因

• 查找路径的线性增长
• 单层镜像：只需检查 upperdir + 1 个 lowerdir
• 100 层镜像：最坏情况需检查 upperdir + 100 个 lowerdir
• 时间复杂度：O(n)（n 为镜像层数）
• 缓存失效问题
• Page Cache 局限性：内核缓存（Page Cache）主要优化已访问文件的重复读取，但对首次查找路径无加速效果。
• 负面案例：若频繁访问不同层级的文件（如容器启动时加载分散在各层的 .so 库），会导致大量目录项（dentry）缓存未命中。

5.2.2 文件与目录的删除逻辑

(1) 文件删除

容器内删除文件时，会在容器层（upperdir）创建空白文件（whiteout file）。镜像层（lowerdir）中的原始文件仍保留（因其只读属性），但空白文件会阻止容器访问该文件

(2) 目录删除

容器内删除目录时，会在容器层生成不透明目录（opaque directory）。其作用机制与空白文件类似，即使该目录仍存在于镜像层，容器也无法访问

5.2.3 目录重命名的限制条件

仅当源路径和目标路径均位于容器顶层（upperdir）时，才能成功调用rename(2)进行目录重命名。否则系统将返回EXDEV错误（"跨设备链接不允许"）。应用程序需设计相应的异常处理机制，通常需回退到"复制+解除链接"的替代方案。

• 首次写入采用copy_on_write机制，保持镜像层不可变性
• 空白文件实现原理：通过字符设备c 0 0标记实现删除效果
• EXDEV错误源于OverlayFS的存储架构特性，需应用层特殊处理

虽然目录的 rename(2) 系统调用本身受 EXDEV 限制，但 OverlayFS 在用户态模拟了跨层重命名：先通过 copy_up 将整个目录树复制到 upperdir。然后在 upperdir 内部执行原子性重命名

6 参考资料

• [1] https://docs.docker.com/engine/storage/drivers/overlayfs-driver/