Linux 磁盘空间排查：df 与 du 打架的三个原因

df 说满了，du 说没满

运维里最经典的“罗生门”：df -h 显示磁盘 98%，du -sh 逐层加起来却对不上。两边都没错，只是统计口径不同——df 看的是文件系统级占用，du 看的是目录树里还能被遍历到的文件。对不上账，通常是下面三个原因之一。

原因一：文件已删除，进程还抓着不放

日志被 rm 掉了，但写它的服务（比如 nginx、java 进程）还开着文件描述符，空间实际还被占着，du 自然看不到。定位命令：lsof | grep deleted 或 lsof +L1，列出“已删除但仍在占用”的文件和处理它们的进程。最小代价的释放姿势：重启对应服务；不能重启的场景用 >/path/to/file 把文件描述符指向的文件清空（truncate 到 0），注意是清空不是新建。

原因二：挂载点遮蔽

往 /data 里存文件之前，/data 上曾经挂过一块云盘；后来云盘卸载了，文件留在了根分区的 /data 目录里。云盘再挂回来时，旧文件被“盖”在挂载点下面，du 进不去、df 却还在根分区里老老实实记着账。排查：对可疑挂载点用 mount | grep 该目录 看叠加关系；确认后 umount 再 du，就能看见被遮住的“地下层”。

原因三：稀疏文件与预留块

某些数据库和虚拟化场景会产生稀疏文件，du 与 df 的统计口径差异会被放大，还会遇到 ls 看到的逻辑大小和 du 实际占用对不上的情况。这类账目差异一般无害，先看前两个原因，最后才考虑它。

定位与释放的推荐顺序

1）df -i 确认是不是 inode 被小文件吃光（另一种“满”）；2）lsof | grep deleted 找幽灵文件；3）du -x -d2 --max-depth 逐层找大头（-x 别跨文件系统）；4）确认进程再动文件，宁可 truncate 不轻易 rm；5）最后重启兜底。清理之后 df 和 du 终于“和好”，同时记得把滚动日志交给 logrotate，别再手工 rm live 日志。

小结

df 与 du 打架，十次有九次是“进程还抓着已删除文件”，剩下一成多半是挂载点遮蔽。记住 lsof | grep deleted 这一条命令，磁盘告警的半夜就少熬一半。