私は、/dev/xvdb にマウントされたストレージを持つ Amazon AWS インスタンスを持っています。これは「通常の」/mnt/build_tmp です。これは約 70 GB (正確には 66,946,696 KB) です。これに書き込もうとすると、どうやらいっぱいだったようです。これはありそうになかったので、確認したところ、約 11 GB のファイルがありました (「du」によると) が、/mnt (/mnt/build_tmp のみを含む) は 100% いっぱいでした (「df」によると)。1 つ (大きな 5.5 GB の tar ファイル) を除くすべてのファイル (約 6 GB 相当) を削除したところ、約 6 GB の空き領域ができました。正確には、現時点での状況は次のとおりです。
ubuntu@ip-172-31-60-67:/mnt$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8115168 6083076 1596816 80% /
none 4 0 4 0% /sys/fs/cgroup
udev 7689964 12 7689952 1% /dev
tmpfs 1540092 780 1539312 1% /run
none 5120 0 5120 0% /run/lock
none 7700456 72 7700384 1% /run/shm
none 102400 8 102392 1% /run/user
/dev/xvdb 66946696 57365136 6174200 91% /mnt
ubuntu@ip-172-31-60-67:/mnt$ du
5773532 ./build_tmp
du: cannot read directory ‘./lost+found’: Permission denied
16 ./lost+found
5773552 .
ubuntu@ip-172-31-60-67:/mnt$ ls
build_tmp/ lost+found/
ubuntu@ip-172-31-60-67:/mnt$ ll build_tmp/
total 5.6G
drwxr-xr-x 2 ubuntu 4.0K Sep 18 18:33 ./
drwxr-xr-x 4 root 4.0K Aug 25 18:43 ../
-rw-rw-r-- 1 ubuntu 5.6G Sep 17 00:38 archive.tar.gz
誰かこれを説明できますか? このようなことは今まで見たことがありません。これは何らかの形で AWS の結果であると考えていますが、もっと一般的なものかもしれません。
いずれにせよ、ディスク上の失われた 50 GB 以上のスペースを回復する必要があります。
[追記: スーパーユーザーの質問「なぜ df は du と違うのか」はすでに確認しましたが、私の問題とは関係がないように思われます。]
答え1
これは、ここで説明した問題のバリエーションであることがわかります。
https://serverfault.com/questions/454194/ec2 インスタンス上のディスク スペースが不足し、ファイル ディレクトリが不足しています
そこに記述された解決策がこの問題の解決策でした。
削除されたファイルがプロセスによってまだ開かれている場合、プロセスがファイルを閉じる (または強制終了する) まで、スペースは再利用されません。ファイルを開いたままにしているプロセスを特定できない場合は、再起動すると実行中のプロセスがすべて閉じられるため (したがって開いているファイルもすべて閉じられるため)、役に立ちます。
開いているプロセスを見つけて終了すると、スペースが回復されました。