docker镜像分层原理是分析存储驱动性能的起点：镜像由只读增量层堆叠构成，每层仅存与前层差异，容器运行时添加可写层；存储驱动决定层的物理组织、联合挂载及读写处理方式，从而导致性能差异。
理解Docker镜像分层原理是分析不同存储驱动性能表现的起点。镜像本身由只读增量层堆叠构成，每层仅保存与前一层的差异；容器运行时在此之上叠加一个可写层。存储驱动（如 overlay2、aufs、devicemapper）并不改变这一逻辑分层结构，而是决定这些层在宿主机上如何物理组织、如何联合挂载、以及如何处理读写请求——正是这些底层实现细节，直接导致性能差异。
分层结构如何影响I/O效率
所有存储驱动都依赖“写时复制”（CoW）机制，但实现方式不同：
- overlay2：内核原生支持，通过 upperdir + lowerdir + workdir 三目录联合挂载，文件查找和修改只需路径拼接与元数据操作，开销极小
- aufs：需用户态补丁支持，多层遍历路径更长，尤其在层数多（>10层）或频繁 stat/open 操作时，元数据延迟明显上升
- devicemapper：基于块设备快照，每次文件写入可能触发整个块（默认64KB）复制，小文件随机写性能显著下降，且存在 thin pool 碎片与空间回收延迟问题
层共享能力决定构建与拉取速度
镜像层复用依赖驱动对“相同内容哈希层”的识别与挂载效率：
- overlay2 和 aufs 都支持按 content-addressable 方式复用 diff 目录，但 overlay2 的 inode 复用更稳定，构建中缓存命中后几乎不触发磁盘写
- zfs 和 btrfs 虽也支持快照共享，但需额外配置压缩/去重，且镜像层无法直接映射为原生存储快照，实际复用率常低于预期
- devicemapper 对层的抽象是块级而非文件级，相同文件内容若散落在不同块中，无法跨层去重，拉取多个相似镜像时磁盘占用接近线性增长
可写层行为暴露驱动真实负载特征
容器运行时的写入模式会放大驱动差异：
- 日志类应用（高频追加小文件）：overlay2 表现平稳；aufs 在高并发 open() 下易出现目录项锁争用；devicemapper 可能因频繁 snapshot commit 导致 write stall
- 数据库类应用（大量随机读写）：zfs/btrfs 启用 ARC/L2ARC 或写时压缩后可能反超 overlay2；但 overlay2 配合 XFS 文件系统仍是低延迟首选
- 临时编译场景（大量创建删除文件）：overlay2 的 unlink 性能最优；aufs 删除深层嵌套路径耗时随层数增加；devicemapper 则需等待 block 回收，延迟不可控
内核与文件系统协同才是关键变量
同一驱动在不同环境表现可能迥异：
- overlay2 在 ext4 上表现均衡，在 XFS 上开启 inode64 + ftype=1 后，大镜像启动速度提升约 20%
- aufs 已从主流内核移除，Ubuntu 22.04+ 默认不带模块，强行加载易引发 panic
- zfs 需独立安装 zfsutils-linux，其 ARC 缓存若未预留足够内存，反而会加剧 swap 压力
不复杂但容易忽略：性能不是由驱动名字决定的，而是由“镜像层访问路径长度 + 可写层写入粒度 + 宿主机文件系统特性”三者共同约束的。选型时应以实际 workload 的 I/O trace 为依据，而非默认推荐。
