graphdriver 是 docker 镜像与容器文件系统的抽象层，统一调度底层存储技术实现分层、cow 和读写隔离；其演进从 aufs 到 devicemapper 再到 overlay2，本质是适配内核成熟度与运维需求的“文件系统翻译器”；docker 25.0+ 已移除 devicemapper，27.0+ 强制弃用 overlay2 并拒绝启动旧数据，迁移需校验内核与 d_type、备份数据、精准配置、彻底清理并验证启动、复用与回收。
graphdriver 是 Docker 镜像与容器文件系统的核心抽象层，它不直接处理业务逻辑，而是统一调度底层存储技术来实现镜像分层、写时复制（CoW）、容器读写隔离等关键能力。它的演进不是技术炫技，而是为解决真实生产痛点：从早期仅适配 Ubuntu 的 AUFS ，到兼顾老内核兼容性的 devicemapper ，再到如今默认且轻量高效的 overlay2 ，每一步都对应着内核支持成熟度、并发稳定性与运维复杂度的权衡。
graphdriver 本质是“镜像与容器的文件系统翻译器”
它把用户看到的“拉一个镜像、启一个容器”翻译成操作系统能执行的动作：比如把 5 层只读镜像叠加成一个视图、在容器启动时挂载可写层、记录哪块磁盘空间属于哪个镜像层。不同 driver 对应不同翻译策略：
- AUFS：靠内核模块实现多目录联合挂载，Ubuntu 曾长期独占支持，但维护碎片化，2018 年后逐步退出主流
- devicemapper：绕过文件系统，用块设备 + thin-pool 管理镜像层，隔离强但 I/O 路径长，元数据开销大，loop-lvm 模式在高负载下易抖动
- overlay2：基于内核原生 overlayfs，用 upperdir/lowerdir/workdir 三目录模型，依赖 d_type 支持（xfs 推荐，ext4 需开启 dir_index），inode 共享效率高，mount/unmount 延迟低
为什么必须迁出 devicemapper？不只是“推荐”，而是“倒计时”
这不是版本迭代的常规优化，而是强制性生命周期终结：
- Docker 25.0+ 已完全移除 devicemapper 支持，无法再安装或启用
- Docker 27.0+ 不仅弃用 overlay2，更将 overlay2 视为不兼容旧数据格式——若检测到 /var/lib/docker/image/overlay2 目录，daemon 将拒绝启动并报错 FATAL: storage driver overlay2 is deprecated and disabled in v27+
- devicemapper loop-lvm 模式在生产环境常见 I/O 不稳定、空间回收滞后、thin-pool 自动扩容失败等问题，排查成本远高于迁移成本
从 devicemapper 到 overlay2 的平滑迁移实操要点
迁移不是简单改配置重启，需兼顾数据安全、服务连续性和验证闭环：
-
前置校验不可跳过：运行
docker info | grep "Storage Driver"确认当前为 devicemapper；检查内核版本 ≥ 4.0（uname -r）；用xfs_info /或tune2fs -l /dev/sdX | grep "Filesystem features"验证是否支持 d_type（xfs 必须 ftype=1，ext4 需挂载选项 dir_index） -
备份必须含两部分：一是完整 /var/lib/docker（含镜像、容器状态、卷），二是关键业务镜像导出为 tar 包（
docker save -o backup.tar image1 image2），避免迁移失败后重建耗时 -
配置修改要精准：编辑 /etc/docker/daemon.json，仅保留
{"storage-driver": "overlay2"}，不要混入其它参数；如内核未满足 d_type 要求，可临时加"storage-opts": ["overlay2.override_kernel_check=true"]，但仅限测试环境，生产务必修复文件系统 -
清理动作有顺序：先停服务（
systemctl stop docker），再删 /var/lib/docker（不是 mv，是 rm -rf），最后 systemctl start docker —— 因为 overlay2 启动时会重建目录结构，残留旧数据会导致 daemon 启动失败
迁移后必须验证的三项事实
不能只看 “Storage Driver: overlay2” 就认为成功：
- 容器能正常启动：拉 nginx 镜像并 run -d -p 8080:80 nginx，curl localhost:8080 返回欢迎页
- 镜像层可复用：用同一基础镜像构建两个不同应用，观察 /var/lib/docker/overlay2 下 layer ID 是否被多个镜像共用（查看 l 目录软链接指向）
-
空间自动回收：删掉已停止容器（
docker rm）和无用镜像（docker rmi）后，df -h /var/lib/docker应明显释放空间，overlay2 不需要手动 dmsetup 或 wipefs
