磁盘满了先别急着扩容：df 和 du 对不上时五步定位

云服务器报磁盘满，第一反应往往是"扩容吧"。但有一种情况扩容也白搭：df 显示满了，du 却统计不出大文件。空间不是被文件占了，就是被别的东西"藏"起来了。先按下面五步定位，找对地方再动手。

第零步：先确认两人看的是同一块盘

df 和 du 的口径不一样，直接对比容易误判：

df -h
du -sh -x /*

判断标准：df 看的是整个挂载点，du 加 -x 才不跨文件系统。先确认你查的目录和满的那块盘是同一个挂载点，别拿 / 的数字去跟 /data 的目录比。

第一步：最常见——文件删了，进程还占着

文件被 rm 删了，但有进程还拿着它的句柄，空间不会释放，du 也统计不到它：

lsof +L1

判断标准：看到 (deleted) 字样的就是这类。处理办法是重启持有它的那个服务、让进程退出释放句柄，而不是继续删别的文件。动手前先确认那是什么服务，别乱杀不认识的进程。

第二步：挂载点盖住了旧文件

新挂载点盖在旧目录上之后，下层原来的文件就被"盖住"了：du 走新挂载点看不到它们，df 却照算那块盘：

mount | grep '你要查的目录'

判断标准：如果该目录确实被挂载过，就要想办法看到下层——比如把上层临时移到别处、或用 bind 挂载的方式看下层内容。确认是下层文件在占空间后，再决定移走还是删掉。

第三步：查 inode 和预留空间

磁盘没满、文件也不大，但写不进去，还可能是 inode 用完了，或者是文件系统给 root 预留的那部分：

df -i

判断标准：df -i 的 IUse% 到 100%，就是小文件太多把 inode 耗光了——这时删大文件没用，要清掉大量小文件。ext4 默认还会给 root 预留一部分空间，普通用户看到的"可用"会比实际少，这是正常设计，不是故障。

第四步：日志是最常见的真凶

确认不是上面三种"藏起来"的情况，再去找真正的大文件，先看日志：

du -sh /var/log/*
journalctl --disk-usage

判断标准：先看是哪个日志目录在涨，再看是哪个服务在写。清理时优先用日志自带的轮转和清理办法（比如 journalctl --vacuum-size=），别直接把正在被写的文件 rm 掉——那样又会回到第一步的 deleted 句柄问题。

第五步：清理后复查，再决定要不要扩容

每清一处就复查一次：

df -h

判断标准：df 的已用真的降下来了，才算找到地方。如果五步走完都没找到、或者找到的地方清完还是满，那才是扩容或迁移数据的信号——这时扩容花的钱才花在刀刃上。

小结

顺序是：对口径 → 查 deleted 句柄 → 查挂载覆盖 → 查 inode/预留 → 查日志 → 复查再定扩不扩。df 和 du 对不上时，问题往往不在文件大小，而在"文件去哪了"这一步。