我如何找出是什么占用了我的 / 分区上的所有空间?

我如何找出是什么占用了我的 / 分区上的所有空间?

我在 Amazon 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 的大小。

这是否意味着我的磁盘有问题?如果是,我该如何修复?

答案1

完全有可能你有一个非常大的已删除文件(或许多小文件),而某个进程仍然拥有打开的文件句柄。找到它们的方法是运行

# lsof | grep "deleted"

如果您看到很多以“(已删除)”结尾的行,那么您可以找到打开这些行的进程 ID 并重新启动它。一旦发生这种情况,您的磁盘空间应该会恢复。

如果这不能解决问题,那么我建议进行 fsck。

答案2

有很多原因导致 du 不等于 df。请参阅这个问题

有些是覆盖挂载,包含大量小文件和较大的块大小,以及仍在使用的已删除文件。覆盖挂载是指将文件系统挂载到包含文件的挂载点上,因此 du 看不到它们。

两者的主要区别在于 df 只检查超级块并信任它,而 du 会扫描它能够看到的所有文件,然后将它们加起来。参见IBM 链接了解有关超级块的信息。

答案3

解决此类问题时,请务必使用 du 的 -x 选项。它可防止 du 跨越文件系统。

相关内容