Docker镜像分层设计影响存储驱动性能与资源利用率，需结合构建方式、层变更频率等选型：overlay2推荐默认，devicemapper已弃用，aufs内核已移除；层复用率决定磁盘效率，overlay2/fuse-overlayfs支持跨镜像硬链接；构建层分裂策略和运行时容器密度进一步约束驱动适配。
Docker 镜像分层是其核心设计之一，直接影响存储驱动的性能表现和资源利用率。选型时不能只看文档里的“支持列表”，得结合镜像构建方式、层变更频率、读写比例等实际使用特征来判断。
分层结构决定写时复制（CoW）压力
每个镜像层都是只读的，容器启动时叠加一个可写层。当应用频繁修改文件（如日志追加、缓存生成），不同存储驱动对“写时复制”的处理差异会立刻显现：
- overlay2（推荐默认）：依赖 inode 硬链接共享只读层，元数据操作轻量，适合层数多、变更集中在顶层的场景；
- devicemapper（已弃用）：块级 CoW 开销大，小文件高频写入易触发 thin-pool 扩容和碎片，延迟明显上升；
- aufs（内核已移除）：层间合并逻辑复杂，层数超 10 层后 mount/unmount 耗时陡增，不适用于 CI/CD 中快速拉取/丢弃镜像的流程。
镜像层复用率影响磁盘空间与拉取效率
企业环境中，基础镜像（如 python:3.9-slim、node:18-alpine）往往被数十个业务镜像共用。存储驱动需高效复用底层只读层：
- overlay2 和 fuse-overlayfs 原生支持跨镜像层硬链接，相同内容层只存一份，节省 30%~60% 磁盘空间；
- btrfs 虽支持写时复制和快照，但需手动 balance 清理未引用块，且镜像层哈希匹配失败时会重复存储；
- zfs 需开启 recordsize=4K 并禁用压缩才能避免小文件写放大，配置不当反而降低层共享效率。
构建阶段的层分裂策略倒逼驱动适配
Dockerfile 中每条指令生成一层，但并非所有分层都合理。例如把 apt update && apt install 拆成两行，会导致中间层残留大量缓存包，增大镜像体积和层比对开销：
- overlay2 对深度嵌套的层（>15 层）仍保持稳定 mount 性能，适合多阶段构建中精细控制清理时机；
- 某些旧版 storage driver（如 aufs）在层过多时触发内核 page cache 冲突，导致 docker build --no-cache 过程中反复 re-read 基础层；
- 若团队普遍使用 BuildKit（启用 RUN --mount=type=cache），overlay2 的 dentry 缓存机制更能减少重复挂载开销。
运行时容器密度与驱动 I/O 特性需匹配
单机部署上百容器时，存储驱动的并发文件打开、inode 分配、目录遍历效率成为瓶颈：
- overlay2 在 ext4/xfs 上支持 d_type=1，readdir() 可直接过滤白名单项，大幅加速容器启动时的层合并；
- devicemapper 使用 loop-lvm 模式时，每个容器独占一个 thin device，高密度下 metadata server 成为热点；
- 若宿主机用 btrfs 或 zfs，建议直接使用 native 驱动而非 overlay2，避免双层 CoW 叠加引发 write stall。
