Linux 磁盘空间告急：用 df 与 du 快速定位并安全清理的实战

服务器最让人头疼的故障之一，就是磁盘突然写满：服务写日志失败、数据库拒绝写入，而 df 一看，Use% 已经到了 100%。这篇文章讲清楚 df 与 du 的分工，以及哪些能删、哪些千万别碰。

一、先看整体：df 回答“哪块盘满了”

df -h

按人类可读的方式显示每个挂载点的总容量、已用、可用和挂载点。重点不是看根分区有多大，而是看哪个挂载点先满：根分区满、/var 满、/home 满，处理思路完全不同。

如果 df 显示还有空间却写不进去，就要怀疑 inode 耗尽：

df -i

看 IUsed% 这一列。小文件成千上万时，空间没满、inode 先满，同样写不进去，这时删大文件没有用，得清理大量小文件。

二、再找大户：du 回答“空间被谁吃了”

知道哪个挂载点满了，再用 du 逐层下钻：

du -h --max-depth=1 /var | sort -rh | head

这条命令列出 /var 下一级子目录的大小，并按大小倒序排列。找到最大的目录后，把路径换成它，再深入一层，两三轮就能锁定大户。不要一上来就 du -h /，全盘扫描又慢又吵，还会把挂载的远程目录也算进去；先用 -x 把扫描限制在同一个文件系统内。

三、三种常见的“假满”和“真满”

第一种是已删除但仍被占用的文件：日志被 rm 删掉，进程还握着句柄，空间不会释放。用 lsof | grep deleted 可以看到这类文件，正确做法是重启对应服务，或者用 : > 文件名 的方式截断日志，而不是直接删正在写的文件。

第二种是日志失控：某个服务开启了 debug 日志，一夜写出几十 GB。先用 journalctl --disk-usage 看 systemd 日志占了多少，再用 journalctl --vacuum-size=500M 做有上限的清理，比手动删 /var/log/journal 更安全。

第三种是缓存和临时文件堆积：包管理缓存、旧内核、构建产物和 /tmp 下的过期文件。清理前先确认它们可以重建或重新下载，生产环境尤其要先备份关键配置。

四、可以安全清理的清单

按风险从低到高：包管理器缓存 apt clean 或 yum clean all；journalctl --vacuum-time=7d 只保留最近七天的系统日志；/tmp 和 /var/tmp 里超过一周的临时文件；自己确认无用的旧备份和构建产物；轮转后残留的 .gz 旧日志。清理完立刻再跑一次 df -h，确认可用空间回升，并看一眼服务日志是否恢复正常写入。

千万别碰的几类：正在运行的数据库数据目录、/etc 下的配置文件、不知道归属的 /opt 或 /usr/local 子目录，以及任何没有备份的生产数据。磁盘满的时候最忌“先删了再说”，删错的代价比磁盘满大得多。

五、让磁盘不再半夜告急

治标之后要治本：给日志加上 logrotate 轮转，限制单个日志文件大小和保留份数；对关键挂载点做磁盘使用率告警，85% 提醒、95% 紧急处理。df 与 du 都不复杂，难的是养成“先定位、再确认、后清理”的顺序。磁盘告急时不慌，按挂载点、目录、文件三层下钻，大多数问题十分钟内就能找到元凶。