我有一个服务器（硬件Raid 1），32G，ext3 filesytem SCSI磁盘。 df告诉我，磁盘是100％满的。 如果我删除1G这是正确显示。
但是，如果我运行一个du -h -x /那么du告诉我只有12G被使用（因为一些Samba使用了-x ）。
所以我的问题不是关于du和df命令之间的细微差别，而是关于如何找出导致这种巨大差异的原因？
我重新启动了机器的fsck去了w / out错误。 我应该运行badblocks吗？ lsof显示我没有打开删除的文件， lost+found是空的，在消息文件中没有明显的warn / err / fail语句。
随意问一下设置的更多细节。
检查位于挂载点下的文件。 如果将一个目录（比如sambafs）挂载到一个已经有一个或多个目录的文件系统上，经常会失去查看这些文件的能力，但是它们仍然占用底层磁盘上的空间。 我已经在单用户模式转储文件中的文件拷贝到除了单用户模式（由于其他目录系统被安装在其上）之外我看不到的目录。
当试图追踪本地服务器上的问题时，偶然发现了这个页面。
在我的情况下， df -h和du -sh大约有50％的硬盘大小不匹配。
这是由apache（httpd）在内存中保存大量的日志文件引起的，这些文件已经从磁盘上删除了。
这是通过运行lsof | grep "/var" | grep deleted追踪的 lsof | grep "/var" | grep deleted 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的磁盘空间。
我同意OldTroll的回答，认为这是“失踪”空间最可能的原因。
在Linux上，您可以轻松地将整个根分区（或其他任何分区）重新挂载到文件系统中的另一个地方例如/ mnt，只需发出一个
mount -o bind / /mnt
那么你可以做一个
du -h /mnt
看看什么东西用完你的空间。
诗：对不起，添加一个新的答案，而不是一个评论，但我需要一些格式的这个职位是可读的。
看看df -i说什么。 这可能是因为你没有使用inode，如果这个文件系统中有大量的小文件，就会发生这种情况。这个文件系统会占用所有可用的inode而不消耗所有的可用空间。
在我的情况下，这与大删除的文件。 在find这个页面之前解决起来相当痛苦，这使我走上了正确的道路。
我终于用lsof | grep deleted解决了这个问题 lsof | grep deleted ，这显示了哪个程序拥有两个非常大的日志文件（总计5GB的可用8GB根分区）。
由程序打开的文件在删除时不会真正消失（停止使用磁盘空间），而在程序closures时它们会消失。 一个程序可能有一个巨大的临时文件，你（和）不能看到。 如果是僵尸程序，则可能需要重新启动以清除这些文件。
试试这个来看看是否仍然写入死/挂进程，同时仍然写入磁盘：lsof | grep“/ mnt”
然后尝试杀死任何卡住的PID（尤其是查找以“（已删除）”结尾的行）
这是我发现迄今为止find大文件的最简单的方法！
这里是一个例子，如果您的根挂载已满/（mount / root）示例：
CD / （所以你在根）
ls | xargs du -hs
输出示例：
9.4M bin 63M启动 4.0K cgroup 680K开发 31M等 6.3G的家 313M lib 32M lib64 16K输了+find了 61G媒体 4.0K mnt 113Mselect du：不能访问`proc / 6102 / task / 6102 / fd / 4'：没有这样的文件或目录 0 proc 19M根 840K跑 19M sbin 4.0K selinux 4.0K srv 25G商店 26M tmp
那么你会注意到， 商店是大的做一个CD /商店
并再次运行
ls | xargs du -hs
示例输出： 109M备份 358M fnb 4.0G iso 8.0K ks 16K输了+find了 47M根 11M脚本 79M tmp 21G vms
在这种情况下，vms目录是空间猪。
所以我在Centos 7中也遇到了这个问题，并且在尝试了一些像bleachbit和清理/ usr和/ var之类的东西之后find了一个解决scheme，尽pipe它们每个只显示了大约7G。 仍然显示50G根分区中使用的50G，但只显示了9G的文件使用情况。 运行一个真正的Ubuntu的CD和卸载有问题的50G分区，打开terminal，并在分区上运行xfs_check和xfs_repair。 然后我重新安装了分区，我的lost + found目录已经扩展到了40G。 按大小sortingfind了丢失的+，发现一个38G文本日志文件的蒸汽，最终只是重复了一个MP3错误。 删除了大文件，现在有空间，我的磁盘使用量与我的根分区大小一致。 我仍然想知道如何让蒸汽日志不会再那么大。
如果挂载的磁盘是Windows机器上的共享文件夹，那么似乎df将显示整个Windows磁盘的大小和磁盘使用情况，但是du只会显示您有权访问的磁盘部分。 （并被安装）。 所以在这种情况下，问题必须固定在Windows机器上。
再考虑一个可能性 – 如果您使用的是docker，几乎可以保证看到一个很大的差异，并且在使用卷挂载的容器内运行df / du。 在docker主机上挂载一个目录的情况下，df将报告主机的df总数。 如果你仔细想想，这是显而易见的，但是当你得到一个“充满磁盘的失控容器！”的报告时，确保你用du -hs <dir>这样的东西来validation容器的文件空间消耗。
检查/失去+find，我有一个系统（centos 7）和一些文件在/失去+find吃了所有的空间。