我在 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
答案3
解决此类问题时,请务必使用 du 的 -x 选项。它可防止 du 跨越文件系统。