我有一个 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
事实证明这是此处描述的问题的变体：
那里描述的解决方案就是解决这个问题的。
如果已删除的文件仍被某个进程打开，则空间将不会被回收，直到该进程关闭该文件（或被终止）。如果您无法确定哪个进程正在打开某个文件，则重新启动将有所帮助，因为这样将关闭所有正在运行的进程（从而关闭所有打开的文件）。
一旦我找到打开的进程并将其终止，空间就被恢复了。