docker 占满根分区时先分清谁在吃盘

挪 data-root 是最后一招，分区真被顶死了才动它。

代价很直白：重启 docker 的瞬间，跑着的容器全收一发 SIGKILL，再 up 完 ps -a 一数，退出的全标 137。

这数和 OOM 长得像，可这里 OOMKilled 是 false，两码事别混。

查的顺序我是这么排的：df 先问哪块分区满了，docker system df 再看 docker 名下能回收多少，du 最后揪单个大户，一步只回答一个问题。

CentOS 7.9 加 Docker 20.10.7 这套跑下来三分钟，方向就清楚了。

复制代码

$ df -h / /var/lib/docker
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        59G   56G     0 100% /

这一步回答的是「到底哪块分区顶到墙了」。

根分区没到 100%，就轮不到 docker 背锅；如果 /var 是单独挂的，涨的往往是别处来的东西。

复制代码

$ docker system df
TYPE                TOTAL   ACTIVE  SIZE      RECLAIMABLE
Images              54      11      18.24GB   11.7GB (64%)
Containers          3       3       1.2GB     0B
Local Volumes       6       4       2.1GB     2.1GB (100%)

这一步回答「docker 手里还有多少能动的」。

SIZE 是它实际占的总数，ACTIVE 是真被容器引用的，能下手的额度只看 RECLAIMABLE。

五十几个镜像、在用的十一个，这比例不稀奇。

复制代码

$ du -sh /var/lib/docker/containers/*/*-json.log
3.7G    /var/lib/docker/containers/e7a3f91c0b26/e7a3f91c0b26-json.log

这一步回答「有没有哪个单个文件把盘吃穿了」。

上面那三行不给日志记账，而容器写 stdout 的东西，落点就在宿主的文件上。

一个 json 涨到几个 G，我这边常见。

真要清就两条，顺序不能反：

复制代码

$ docker container prune
$ docker image prune -a

停着的容器会挡 rmi 的路，所以先清容器，再清镜像。

-a 扫得宽：还挂着 tag、但没有容器引用的镜像也一起带走。

落刀前我习惯把 docker images 看两遍，等回滚对层账时才发现丢的那个补不回来。

复制代码

{
  "log-opts": {"max-size": "50m", "max-file": "3"}
}

日志这笔账不靠清，得写进 daemon.json 的 log-opts：max-size 50m、max-file 3，一个容器最多吃一百五十兆。

它只对新生的容器生效，已经养胖的老文件不会自己缩回去。

日志往外翻的办法记在〈logs 刷太快：--tail --since -f -t 四个参数〉那张里，这张只管往回收。

还剩两笔没结：卷上那 2.1GB 到底算谁的，/data 还能不能腾出空间。