我在服务器 (硬件 Raid 1) 中有一个 SCSI 磁盘，32G，ext3 文件系统。df告诉我磁盘已满 100%。如果我删除 1G，则会正确显示。
但是，如果我运行，du -h -x /然后du告诉我只使用了 12G（我使用是-x因为一些 Samba 挂载）。
所以我的问题不是关于 du 和 df 命令之间的细微差别，而是如何找出导致这种巨大差异的原因？
我重启了机器，进行 fsck，结果没有错误。我应该运行吗badblocks？lsof显示没有打开已删除的文件，lost+found是空的，并且消息文件中没有明显的警告/错误/失败语句。
请随时询问设置的更多详细信息。
答案1
检查位于挂载点下的文件。通常，如果您将目录（例如 sambafs）挂载到已经包含文件或目录的文件系统上，您将无法查看这些文件，但它们仍在占用底层磁盘的空间。我在单用户模式下将文件副本转储到我无法看到的目录中，除非在单用户模式下（因为其他目录系统安装在它们之上）。
答案2
尝试追踪本地服务器上的问题时偶然发现了此页面。
就我而言，df -h和du -sh硬盘大小不匹配约50％。
这是因为 apache（httpd）在内存中保存了已从磁盘中删除的大型日志文件。
通过运行“我需要清理的分区lsof | grep "/var" | grep deleted在哪里”可以找到这个问题。/var
输出结果如下：
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)
然后通过重新启动 apache（）解决了该问题service httpd restart，并通过允许清除已删除文件上的锁来清理 2gb 的磁盘空间。
答案3
我同意 OldTroll 的回答，因为这是最可能导致您“丢失”空间的原因。
在 Linux 上，您可以轻松地将整个根分区（或任何其他分区）重新挂载到文件系统中的另一个位置，/mnt例如，只需发出
mount -o bind / /mnt
然后你可以做一个
du -h /mnt
看看是什么占用了你的空间。
答案4
看看上面df -i说了什么。可能是您没有 inode，如果文件系统中有大量小文件，则可能会发生这种情况，这会用尽所有可用的 inode，而不会消耗所有可用空间。