Linux overlay磁盘占满主因是宿主机分区（如/var/lib/docker）中upperdir和workdir残留文件堆积；需用df、du、lsof+L1定位大目录与幽灵文件，再通过docker system prune或重启容器清理。
Linux overlay 文件系统磁盘占满，通常不是因为容器内应用写入了大量数据，而是 overlay 的 lowerdir、upperdir、workdir 所在的宿主机分区被写满，尤其是 upperdir（记录容器层修改）和 workdir（用于 overlay 内部操作）持续积累未清理的文件导致。
检查 overlay 对应的宿主机路径是否已满
OverlayFS 在宿主机上实际使用的是普通目录（如 /var/lib/docker/overlay2/xxx），其空间占用直接反映在宿主机对应挂载点（通常是 /var/lib/docker 所在分区）上：
- 运行
df -h /var/lib/docker查看宿主机分区使用率 - 进入
/var/lib/docker/overlay2，用du -sh * | sort -hr | head -20找出最大的 layer 目录 - 注意：单个 huge upperdir 往往对应一个长期运行且频繁写临时文件的容器（如日志未轮转、缓存未清理、/tmp 未挂 tmpfs）
识别“幽灵文件”：已删除但未释放的 inode
容器内进程可能持有已 unlink 但尚未关闭的文件句柄（例如日志被 logrotate 删除后，老进程仍在写），这些文件仍占磁盘空间，但 ls 不可见：
- 执行
lsof +L1列出所有已删除但仍被打开的文件（+L1 表示 link count = 0） - 重点关注 docker 容器进程（PID 来自
ps aux | grep docker或docker ps -q | xargs docker inspect --format='{{.State.Pid}}'） - 找到对应 PID 后，用
lsof -p $PID查看具体哪些 deleted 文件正在被写入 - 解决方法：重启对应容器，或向进程发
SIGUSR1（若支持日志 reopen）强制其关闭并重建日志文件
overlay2 自身残留与 dangling 数据
Docker 在异常退出、强制 rm 容器、或镜像构建中断时，可能遗留无引用的 layer 目录（dangling），它们不会被自动清理：
- 运行
docker system df -v查看详细空间分布，关注 “Reclaimable” 列和 “Dangling” 标记 - 清理无用数据：
docker system prune -a --volumes（谨慎，会删所有未使用镜像、容器、网络、卷） - 更安全方式：
docker builder prune（清构建缓存）、docker volume prune（清孤立卷）、docker image prune -f（清悬空镜像） - 手动检查
/var/lib/docker/overlay2/*/merged是否存在残留 bind mount 或未卸载的 mountpoint（可用findmnt | grep overlay辅助判断）
预防性配置建议
避免反复陷入磁盘占满困境，需从运行时和部署层面约束：
- 为容器设置
--storage-opt size=10G（仅支持 devicemapper，overlay2 不支持该参数），改用--tmpfs /tmp:rw,size=512m防止 /tmp 写爆 - 在容器内强制日志驱动限制：
docker run --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 ... - 对写密集型容器，挂载 hostPath 或 emptyDir（K8s）到独立大分区，并配 disk quota（如
setquota或 XFS project quota） - 定期巡检脚本：监控
/var/lib/docker使用率 +lsof +L1 | wc -l+docker system df --format "{{.Reclaimable}}"
