# df -h /
Filesystem Size Used Avail Use% Mounted on
rootfs 9.9G 7.2G 2.2G 77% /
# du -hx --max-depth=0 /
3.2G /
如您所见，df显示已使用 7.2GB，但du只能找到其中的 3.2GB。自从我注意到这一点以来，服务器已经重新启动，因此这不是已删除的文件。此外，lsof没有显示任何有趣的内容。还能是什么？
答案1
我在 ext4 系统上遇到了完全相同的问题，我只想发布我的解决方案以供将来参考。当我的驱动器最初填满时，我从 /var/log 中删除了一堆日志。这清理了几 GB，但几天后我又用完了空间，而 du -h 和“mount --bind / /mnt”没有指向罪魁祸首。最终当我运行 lsof 时找到了它。
lsof ... rsyslogd 1766 root 2w REG 9,1 12672375940 264014 /var/log/messages (已删除) ...
当我删除消息日志文件时，rsyslog 服务仍将其保持打开状态，但处于隐藏状态。运行“touch /var/log/messages;service rsyslog restart”可解决问题，我的磁盘空间也已恢复。
lsof 的输出可能有点让人不知所措，特别是如果你的系统很忙（我的系统有超过 1000 行）。如果你在 lsof 输出中 grep “deleted”，它应该有助于查明问题进程。
答案2
既然您使用了此-x选项，我假设您已安装其他文件系统？可能是您在非空目录上安装了另一个分区。
答案3
确保挂载点“后面”的所有文件夹都是空的。根据我的经验，我认为您很可能在挂载点后面隐藏了一些数据。
您可以检查挂载点后面的文件夹中的内容，而无需卸载磁盘/分区（如果您必须卸载 /usr，那么这会很有用）。只需执行
# mount --bind / /mnt
# du -shx /mnt
另外补充一下：
# du -shx /
和你的 du 一样...但是要短得多（-s 代表总结）
答案4
可能存在以下几个问题：(1) 进程打开了一个大文件或多个文件，但这些文件已被删除；或者 (2) 您可能遇到了某种文件系统问题，可以通过对驱动器进行 fsck 来解决。但是，这只能在驱动器未安装时执行。一些 Linux 提供了在启动时对根文件进行 FULL fsck 的方法，方法是：
touch /forcefsck
然后重新启动。我知道 SuSE 和 RedHat 版本中都存在这种情况。