我在亚马逊的EC2服务器上的一个大型实例。 我运行df命令并得到：
root@db:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 9.9G 9.1G 284M 98% / tmpfs 3.8G 0 3.8G 0% /lib/init/rw varrun 3.8G 116K 3.8G 1% /var/run varlock 3.8G 0 3.8G 0% /var/lock udev 3.8G 80K 3.8G 1% /dev tmpfs 3.8G 0 3.8G 0% /dev/shm /dev/sdb 414G 957M 392G 1% /mnt /dev/sdf 50G 12G 35G 26% /byp /dev/sdk 99G 31G 63G 33% /backups 然后我运行du命令并得到：
root@db:/# du -s -h /* 31G /backups 5.5M /bin 136K /boot 12G /byp 80K /dev 5.8M /etc 12K /home 70M /lib 11M /lib32 0 /lib64 16K /lost+found 759M /mnt 4.0K /opt du: cannot access `/proc/6917/task/6917/fd/4': No such file or directory du: cannot access `/proc/6917/fd/4': No such file or directory 0 /proc 31M /root 7.7M /sbin 4.0K /selinux 4.0K /srv 0 /sys 11M /tmp 1.1G /usr 114M /var
如果你注意到，当你在非挂载目录的du命令输出中加上所有的大小时，你将不会在df命令中看到任何接近9.1G的地方。
这是否意味着我有一个坏的磁盘？ 如果是的话，我该如何解决？
这是完全可能的，你有一个非常大的删除文件（或很多小的），一个进程仍然有一个打开的文件句柄。 find它们的方法是运行
# lsof | grep "deleted"
如果你看到很多以“（已删除）”结尾的行，那么你可以find已经打开并重启的进程ID。 一旦发生这种情况，您的磁盘空间应该返回。
如果这不能解决它，那么我会推荐一个fsck。
有一堆理由杜不等于df。 看到这个问题的答案。
有些是覆盖挂载，很多小文件和较大的块大小，以及被删除的文件仍在使用中。 当你在一个挂载点上挂载一个文件系统的时候，挂载挂载是有的，所以du看不到它们。
两者之间的主要区别在于，df只是检查超级块并相信它，du扫描所有可以看到的文件，并将其添加。 请参阅此IBM链接了解有关超级块的信息。
当你正在追逐像这样的问题时，总是使用du的-x选项。 它阻止了跨文件系统。