# 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只能find3.2GB。 服务器已经重新启动，因为我注意到这一点，所以它不是一个删除的文件。 另外， lsof不会给我任何有趣的东西。 还有什么呢？
我在我的ext4系统上遇到了同样的问题，只是想发布我的解决scheme，以备将来参考。 当我的驱动器最初填写完成后，我从/ var / log删除了一堆日志。 这清理了几GB，但在几天之内，我再次跑出空间，杜 – h和“安装 – 绑定/ / mnt”没有指出的罪魁祸首。 终于搞定了，当我跑了。
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“已删除”，则应该有助于查明问题过程。
既然你使用-x选项，我假设你有其他的文件系统挂载？ 这可能是你有另一个分区安装在非空目录的顶部。
可能有几个问题：（1）一个进程有一个大文件或打开的文件数量已经被删除，或者（2）你可能有某种types的文件系统问题通过驱动器的fsck补救。 但是，这只能在驱动器未安装时才能完成。 几个Linux提供了一个在启动时根文件的完整fsck的方法：
touch /forcefsck
然后重新启动。 我知道这存在于SuSE和RedHat varients中。
确保所有安装点后面的文件夹都是空的。 出于经验，我会说最有可能你隐藏在一个挂载点后面的一些数据。
您可以检查挂载点后面的文件夹中的内容，而无需卸载磁盘/分区（例如，如果您不得不卸载/ usr，这可能很好）。 只是做一个
# mount --bind / /mnt # du -shx /mnt
也作为一个方面说明：
# du -shx /
和你的du一样…但是比较短（-s代表总结）