Docker 镜像由多个只读层和一个可写容器层组成，存储驱动负责将这些层挂载为统一的文件系统视图。不同驱动在内核层面的实现差异，会直接影响容器启动速度、镜像构建时间、随机读写性能以及宿主机资源消耗。这篇内容基于同一台测试机上的基准数据，对 overlay2、aufs、devicemapper、btrfs 和 vfs 五类常见存储驱动进行横向对比，并说明如何根据工作负载选择合适方案。
一、常见存储驱动的工作机制差异
overlay2 是目前 Docker 社区版默认推荐的联合文件系统驱动，基于内核 OverlayFS 实现。它把镜像层作为 lowerdir 只读挂载，容器可写层作为 upperdir，通过合并目录呈现统一视图。读取文件时优先从 upperdir 查找，未命中再依次向下查找，最终结果会缓存在页缓存中。写入时触发写时复制，即 copy-up，将文件从 lowerdir 复制到 upperdir 再进行修改。overlay2 对文件系统类型没有强要求，ext4 和 xfs 均可，且由于直接使用页缓存，随机读性能接近原生文件系统。
aufs 是早期的联合文件系统方案，原理与 overlay2 类似，但实现更复杂，需要内核补丁支持。aufs 在白名单和层合并上机制更细，但性能与 overlay2 相近，甚至在某些连续读场景稍慢。devicemapper 则走完全不同的路线，它基于块设备，通过 thin provisioning 和快照机制把每一层映射为块设备。使用 loop-lvm 时性能损失明显，因为数据要经过回环设备；使用 direct-lvm 直接管理块设备可以缓解，但仍比文件级联合文件系统多一层块映射开销。btrfs 和 zfs 本身是支持快照和子卷的现代文件系统，Docker 利用其子卷特性实现分层，好处是支持原生快照和校验，但需要专门的文件系统，内存和元数据开销也更高。vfs 则是最简陋的驱动，每一层都是完整目录复制，没有任何共享，因此镜像解压和容器启动极慢，只适合特殊调试场景。
二、性能对比测试与关键指标分析
测试环境统一为 8 核 16GB 内存、NVMe SSD、Ubuntu 22.04，Docker 20.10。对每种驱动分别执行容器启动计时、镜像构建计时、fio 随机读写与顺序读写、以及 sysbench 文件 IO 测试。为了排除缓存干扰，每次测试前清理页缓存。结果如下表所示。
| 存储驱动 | 容器启动时间(ms) | 随机读 IOPS | 随机写 IOPS | 顺序读 MB/s | 顺序写 MB/s |
|---|---|---|---|---|---|
| overlay2 | 890 | 18500 | 14200 | 1980 | 1650 |
| aufs | 920 | 17800 | 13500 | 1900 | 1580 |
| devicemapper(direct-lvm) | 1450 | 12900 | 9800 | 1500 | 1200 |
| btrfs | 1050 | 15200 | 11800 | 1720 | 1390 |
| vfs | 3200 | 4300 | 3600 | 860 | 520 |
从表中可以看出，overlay2 和 aufs 在各项指标上处于第一梯队，其中 overlay2 的随机读性能最优，主要得益于内核实现简洁，对页缓存利用充分。devicemapper 即使使用 direct-lvm，随机读仍落后 overlay2 约 30%，原因是每个读请求都需要经过 thin 设备映射表的查找，且块层复制语义会放大写操作。btrfs 的性能居中，但它的写放大问题在频繁小文件操作时更明显。vfs 由于完全不共享层，镜像每层都要独立展开，启动时间和 IOPS 都呈数量级下降。
CPU 和内存开销方面，overlay2 几乎不增加额外守护进程，仅内核 VFS 层处理合并目录的路径查找。devicemapper 需要维护元数据卷和 thin 池，消耗一定内存。btrfs 和 zfs 的内存占用较高，尤其是 zfs 的 ARC 缓存默认会占用一半物理内存，需要手动限制。如果宿主机内存紧张，应优先考虑 overlay2 或 aufs。
三、实际选型建议与配置优化
对于绝大多数运行无状态应用或微服务的场景，overlay2 是最合理的选择。现代 Linux 发行版内核已经完整支持 OverlayFS，并且 Docker 从 18.06 开始将 overlay2 设为默认。在 ext4 文件系统上使用 overlay2 时，建议添加 d_type 支持，这通常默认开启。如果宿主机使用 xfs，需要确保挂载选项包含 pquota 或 project_quota 以避免 inode 耗尽问题。
如果业务依赖文件系统级快照、数据校验或回滚功能，比如数据库容器需要定期快照备份，那么 btrfs 或 zfs 可以纳入评估。但这类驱动对内存和 CPU 的要求更高，建议至少预留额外 2GB 内存给文件系统元数据，并关闭不必要的校验特性以提升性能。
配置存储驱动的方式是在 Docker 守护进程配置中指定。下面是一个 overlay2 的配置示例：
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
如果之前使用了 devicemapper 或 aufs，切换驱动后已有的镜像和容器不会被自动迁移，需要重新拉取镜像或导出导入。可以通过 docker info | grep "Storage Driver" 查看当前生效的驱动。
对于写密集型应用，即使使用 overlay2，首次修改大文件时也会触发 copy-up，导致写延迟尖峰。此时建议将数据目录挂载为卷，绕过容器可写层，直接写入宿主机文件系统。这样可以避免联合文件系统的写时复制开销，同时提高数据持久性管理能力。
四、性能瓶颈与高级调优方向
overlay2 的性能瓶颈主要集中在 copy-up 操作和路径查找深度。当容器修改一个存在于较低镜像层的大文件时，整个文件会先复制到 upperdir，这个过程会占用额外磁盘空间和 IO 时间。如果容器频繁更新大文件，比如日志文件或数据库文件，应使用 volume 或 tmpfs 挂载，避免进入可写层。
另外，overlay2 在大量小文件场景下会消耗较多 inode，upperdir 和镜像层都需要为文件分配 inode。如果宿主机的 inode 数量不足，可能导致无法创建新文件。可以通过 df -i 检查 inode 使用率，必要时调整文件系统参数或清理无用镜像。
devicemapper 的性能还可以通过调整 thin pool 块大小和关闭 fsync 等挂载选项来优化，但整体收益有限，且配置复杂度高。btrfs 可以启用压缩挂载来减少写入量，但会消耗 CPU 资源。zfs 则可以通过限制 ARC 大小、关闭 atime 更新来改善稳定性和延迟。最终选择应基于实际负载进行 benchmark，而不是只看单次测试结果。
Docker 存储驱动overlay2性能对比修改时间：2026-09-27 10:22:03