我有一個 Amazon AWS 實例，其儲存安裝在 /dev/xvdb 上，即「通常的」/mnt/build_tmp。約為 70GB（即 66,946,696kB）。試圖寫入它，它顯然已滿。這似乎不太可能，所以我檢查了一下，上面有大約 11GB 的文件（根據“du”），但 /mnt（僅包含 /mnt/build_tmp）已 100% 滿（根據“df”）。我刪除了所有檔案（大約 6GB 的價值），除了一個（這是一個 5.5GB 的大 tar 檔案），現在我有大約 6GB 的可用空間。準確來說，目前的情況是這樣的：
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 的結果，但它可能是更通用的東西。
無論如何，我需要恢復磁碟上遺失的 50GB+ 空間。
[ps我已經檢查了超級用戶問題“為什麼 df 與 du 不同”，它似乎與我的問題無關。
答案1
事實證明，這是此處描述的問題的變體：
那裡描述的解決方案就是這個問題的解決方案。
如果已刪除的檔案仍被某個進程打開，則該空間將不會被回收，直到該進程關閉該檔案（或被殺死）。如果您無法識別保持檔案開啟的進程，則重新啟動將有所幫助，因為這將關閉所有正在運行的進程（從而關閉所有開啟的檔案）。
一旦我找到打開的進程並殺死它，空間就被恢復了。