优先选 overlay2，因其适合高并发小文件读写场景，性能优于 devicemapper 近 3 倍；devicemapper 仅适用于需强快照控制的特定业务，但配置复杂、启动慢、运维成本高。
选 Overlay2 还是 DeviceMapper，关键看你的 I/O 负载类型和运维能力。Overlay2 更适合通用高并发、小文件频繁读写的场景；DeviceMapper 适合需要强快照控制或块级隔离的特定业务，但配置和维护成本更高。
看 I/O 类型：小文件多就选 overlay2
Overlay2 基于文件系统层叠（lowerdir/upperdir），对大量小文件的创建、删除、读取效率极高。比如 Sentry 日志处理、Node.js 应用依赖安装、CI/CD 构建过程，随机写 IOPS 可达 8900，比 devicemapper 高近 3 倍。如果你的应用每秒产生数百个日志条目、频繁拉取 npm 包或编译 TypeScript，overlay2 的启动快、延迟低、IO 等待少，直接反映在响应时间上。
- 典型负载：Web API、微服务、前端构建、错误追踪（如 Sentry）
- 注意点：确保底层文件系统启用 d_type（xfs 默认支持，ext4 需 mkfs 时加 -O dir_index, filetype）
- 风险提示：inode 耗尽常见于镜像含海量小文件，建议 ext4 格式化时指定 -i 16384（每 16KB 分配一个 inode）
看功能需求：要快照回滚才考虑 devicemapper
DeviceMapper 是基于块设备的方案，天然支持 LVM 快照，适合需要精确控制存储生命周期的场景——比如数据库容器定期备份、测试环境一键还原、灰度发布前的存储状态固化。但它每次启动都要初始化 device-mapper 表，容器启动慢 2–3 倍，且 thin-pool 空间管理不当易触发“no space left on device”误报。
- 适用场景：金融类批处理容器、合规审计要求保留完整存储快照、已有 LVM 运维体系
- 硬性要求：必须使用 direct-lvm 模式（loop-lvm 已弃用），需单独划分一块裸设备（如 /dev/sdb）并配置 thin pool
- 运维负担：需监控 thin pool 使用率、定期执行 dmsetup status、处理元数据损坏风险
看系统条件：内核与文件系统决定下限
Overlay2 要求内核 ≥ 4.0（CentOS 7.4+、Ubuntu 16.04+ 均满足），且推荐 xfs 或开启 d_type 的 ext4。DeviceMapper 对内核版本宽容，但依赖 device-mapper 内核模块和用户态工具（如 lvm2），在 WSL2 或容器化宿主机中常因权限或模块缺失失败。
- 快速验证 overlay2 支持：grep -q overlay /proc/filesystems && echo "OK"
- 检查当前驱动：docker info | grep "Storage Driver"
- 生产环境不建议绕过内核检查（如 overlay2.override_kernel_check=true），应升级内核而非妥协
看迁移成本：换驱动等于重建容器生态
两种驱动互不兼容。切换前必须清空 /var/lib/docker（镜像、容器、卷全丢），无法增量迁移。这意味着上线前必须确认所有镜像已推至私有仓库、volume 数据已备份、CI 流水线支持重新拉取构建。
- 安全操作顺序：停 docker → 备份 /var/lib/docker → 清空 → 修改 /etc/docker/daemon.json → 启动 → 验证 docker info
- 自动检测逻辑已集成在主流部署脚本中（如 gh_mirrors/se/self-hosted 的 install/_detect-container-engine.sh），会优先选用 overlay2
- 若已有 devicemapper 生产集群且运行稳定，无性能瓶颈则无需强行切换
