Overlay2 是当前生产环境首选存储驱动，基于内核 overlayfs，支持多层叠加、CoW 和文件级共享，性能优、内存低、兼容好；需内核≥4.0（推荐≥4.15）、ext4/xfs（d_type=true）；禁用已弃用的 aufs 和 deprecated 的 devicemapper。

Overlay2 是当前生产环境的首选存储驱动

在主流 Linux 发行版（如 Ubuntu 20.04+、CentOS 8+、RHEL 8+）上，overlay2 已成为 Docker Engine 默认且推荐的存储驱动。它基于 Linux 内核的 overlayfs 实现，支持多层镜像叠加、写时复制（CoW）、细粒度文件级共享，性能稳定、内存占用低、兼容性好，并原生支持 inode 限制和 quota 控制（需内核 ≥5.11 + 启用 overlay.mount_program）。只要宿主机内核版本 ≥4.0（推荐 ≥4.15），文件系统为 ext4 或 xfs（启用 d_type=true），就可安全使用。

避免在生产中使用 aufs 和 devicemapper

aufs 已被主流内核弃用（自 Linux 5.10 起移除），Docker 自 20.10 版本起彻底停止对其的支持，存在兼容性风险与安全更新缺失问题，不应出现在新部署环境中。
devicemapper（尤其是 loop-lvm 模式）在早期 CentOS/RHEL 7 上曾被默认启用，但其性能差、元数据开销高、空间回收不可靠、不支持 live restore，且 lvm 模式配置复杂、依赖额外存储管理。Docker 官方已将其标记为“deprecated”，仅保留向后兼容，新集群应绕过。

其他驱动适用场景有限，需谨慎评估

btrfs 和 zfs 具备快照、压缩、校验等高级特性，适合对数据一致性或存储效率有强需求的特定场景（如 CI/CD 构建节点需频繁快照回滚），但要求底层文件系统专门配置，运维复杂度高，且容器密度大时可能因元数据压力影响性能。
fuse-overlayfs 主要用于无 root 权限或旧内核（

选择前必须验证的三项关键条件

• 确认内核版本：uname -r ≥ 4.15（overlay2 稳定运行底线）
• 检查文件系统是否启用 d_type：findmnt -o fstype,attr /var/lib/docker 中需含 dtype 标志（ext4/xfs 均需显式开启）
• 验证存储路径不在 LVM thin pool、btrfs subvolume 或 NFS 等不支持 overlay 的后端上 —— Docker 不支持在这些挂载点上运行 overlay2