/パーティションのすべてのスペースを使い果たしているものを見つけるにはどうすればよいですか？

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に近い場所はありません。

これは、不良ディスクがあることを意味しますか？もしそうなら、どうすれば修正できますか？

プロセスがまだ開いているファイルハンドルを持っている非常に大きな削除済みファイル（または多数の小さなファイル）がある可能性は十分にあります。それらを見つける方法は実行することです

# lsof | grep "deleted"

「（削除済み）」で終わる行がたくさんある場合は、それらを開いて再起動するプロセスIDを見つけることができます。それが発生すると、ディスク領域が元に戻ります。

これで解決しない場合は、fsckをお勧めします。

duがdfに等しくない理由はたくさんあります。この質問への回答をご覧ください。

一部には、オーバーレイマウント、多数の小さなファイルと大きなブロックサイズ、削除されたファイルがまだ使用されています。オーバーレイマウントとは、ファイルシステムがマウントされているマウントポイントにファイルシステムをマウントしたときのことで、duには表示されません。

2つの主な違いは、dfはスーパーブロックをチェックしてそれを信頼するだけであり、duは、参照可能なすべてのファイルをスキャンして、それらを合計します。スーパーブロックについては、このIBMリンクを参照してください。

このような問題を追跡する場合は、常に-xオプションをduと一緒に使用してください。ファイルシステムを越えないようにします。