存储驱动是Docker架构中最容易被忽视但又最影响日常体验的部分。不少团队在遇到磁盘占满、容器启动缓慢、镜像拉取异常等问题时排查半天，最后发现根源都在存储驱动的配置上。overlay2 是目前官方推荐的存储驱动，几乎所有主流Linux发行版的默认值都是它，但如果文件系统不支持、配置写错或者不了解它的分层机制，依然会踩到不少坑。这篇文章把 overlay2 的工作原理、配置方法、磁盘管理和故障排查一次性讲透。
overlay2 的工作原理：分层挂载到底是怎么回事
要理解 overlay2 的配置，先要理解它背后的 OverlayFS。OverlayFS 是 Linux 内核 3.18 之后正式合入的联合文件系统，它把多个目录叠加在一起，对外呈现出一个统一的视图。在 OverlayFS 的术语中，有三个核心概念：lowerdir（底层只读目录，可以有多个）、upperdir（上层可写目录）以及 merged（合并后的挂载点，也就是用户和容器看到的最终视图）。
对 Docker 来说，每一层镜像都对应宿主机上的一个目录，容器启动时这些镜像层作为 lowerdir 被叠加，再加上一个容器专属的 upperdir 作为可写层。你在容器里删除或修改文件时，实际发生的是 copy-up 操作：文件从只读层被复制到可写层再修改，原层内容不变。这就是为什么在容器里写文件会占用宿主机空间，而且修改一个大文件时磁盘占用可能翻倍的原因。
相比早期的 overlay（第一代实现）和 aufs，overlay2 支持多层 lowerdir 嵌套，避免了深度过深时的性能退化，同时利用了内核页缓存，读写性能更接近原生文件系统。查看当前使用的存储驱动很简单：
# 查看 Docker 整体信息，存储驱动在靠前的位置 docker info | grep -i storage # 输出示例： # Storage Driver: overlay2 # Backing Filesystem: xfs # Supports d_type: true
这里有个非常关键的指标：Supports d_type 必须是 true。d_type 是文件系统对文件类型信息的支持能力，overlay2 依赖它来正确清理文件。如果显示 false，轻则日志告警，重则镜像层清理失败导致磁盘被撑爆。
存储驱动的配置方法与文件系统选择
存储驱动的配置集中在 /etc/docker/daemon.json 这个文件里。如果该文件不存在，直接创建即可。一个典型的 overlay2 配置如下：
{
"storage-driver": "overlay2",
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
}
}
修改保存后需要重载守护进程才能生效：systemctl daemon-reload && systemctl restart docker。注意重启 Docker 会停止所有正在运行的容器，生产环境务必安排好维护窗口。
文件系统的选择比很多人想象的更重要。overlay2 要求底层文件系统支持 d_type，推荐的组合是：ext4 和 xfs（xfs 需要以 ftype=1 格式化）。可以在格式化时确认：
# 新建分区并格式化为支持 ftype 的 xfs mkfs.xfs -f -n ftype=1 /dev/sdb1 # 验证已有文件系统的 ftype 设置 xfs_info /var/lib/docker | grep ftype # 输出包含 ftype=1 即为正确配置
如果磁盘已经用 ext4 格式化，那基本不用操心，ext4 天然支持 d_type。真正容易出问题的是老旧的 xfs 分区（CentOS 7 早期默认 ftype=0）以及一些非标准文件系统。
另外一个常见需求是把 Docker 的数据目录迁移到独立的大容量磁盘。默认路径是 /var/lib/docker，通过配置 data-root 可以修改：
{
"data-root": "/data/docker",
"storage-driver": "overlay2"
}
迁移已有数据时，建议先停止 Docker，用 rsync -aHAX /var/lib/docker/ /data/docker/ 保留权限和硬链接完整复制，确认无误后再切换配置并重启，旧目录保留一段时间作为回滚手段。
磁盘空间管理与常见报错排查
理解了 overlay2 的分层结构后，磁盘管理就变得有迹可循。容器可写层的膨胀主要来自三类写入：日志文件、临时文件和应用产生的数据。检查空间占用的第一步是用 docker system df 看整体分布，再用 docker system df -v 查看每个镜像、容器、卷的详细占用。
清理操作要谨慎区分对象：docker image prune 清理悬空镜像，docker container prune 清理已停止的容器，docker volume prune 清理未被引用的卷，docker system prune -a 则是核弹级清理，会删除所有未使用的镜像。对于生产环境，建议定期执行温和的清理命令并结合监控告警，而不是等到磁盘满了再抢救。
排查容器可写层占用时，可以借助 docker inspect 找到 upperdir 的真实路径，直接在宿主机上分析大文件：
# 获取容器可写层路径
docker inspect mycontainer --format '{{.GraphDriver.Data.UpperDir}}'
# 输出类似 /var/lib/docker/overlay2/abc123.../diff
# 统计该目录占用，找出大文件
du -sh /var/lib/docker/overlay2/*/diff 2>/dev/null | sort -rh | head -10
最后说几个高频报错。错误一：不支持 d_type，日志中出现 overlay2 警告并提示需要删除 /var/lib/docker 重建，此时唯一彻底的办法是备份数据后用正确的文件系统参数重新格式化。错误二：切换存储驱动后镜像消失，这是因为不同存储驱动的存储格式互不兼容，切换驱动后需要重新拉取镜像。错误三：no space left on device，除了清理空间，还要检查是否 inode 耗尽（df -i 查看），大量小文件场景下 inode 先于磁盘空间用完是很典型的情况。
总体来说，overlay2 的配置本身并不复杂，核心就三点：确认文件系统支持 d_type、通过 daemon.json 显式声明驱动、规划好 data-root 所在磁盘的容量。把这三件事做扎实，再配合定期的空间清理和监控，容器存储层就能长期稳定运行，不会再成为生产环境的隐形炸弹。
Docker存储驱动overlay2配置Docker数据管理修改时间：2026-09-09 19:16:53