Почему du и df не договорились об эфемерном хранилище AWS?

Почему du и df не договорились об эфемерном хранилище AWS?

У меня есть экземпляр Amazon AWS с хранилищем, смонтированным на /dev/xvdb, который является «обычным» /mnt/build_tmp. Он составляет около 70 ГБ (ровно 66 946 696 КБ). При попытке записи на него он, по-видимому, был заполнен. Это казалось маловероятным, поэтому я проверил, и на нем было около 11 ГБ файлов (согласно 'du'), но /mnt (который содержит только /mnt/build_tmp) был заполнен на 100% (согласно 'df'). Я удалил все файлы (стоимостью около 6 ГБ), кроме одного (который был большим tar-файлом на 5,5 ГБ), и теперь у меня около 6 ГБ свободного места. А именно, на данный момент ситуация такова:

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 ГБ+ места на диске.

[P.S. Я уже проверил вопрос суперпользователя «почему df отличается от du», но он, похоже, не имеет отношения к моей проблеме.]

решение1

Оказывается, это вариант проблемы, описанной здесь:

https://serverfault.com/questions/454194/disk-space-keeps-filling-up-on-ec2-instance-with-no-apperent-files-directories

Описанное там решение и было решением этой проблемы.

Если файл, который был удален, все еще открыт процессом, пространство не будет восстановлено, пока процесс не закроет файл (или не будет убит). Если вы не можете определить процесс, который держит файл открытым, то перезагрузка поможет, так как она закроет все запущенные процессы (и, таким образом, закроет все открытые файлы).

После того, как я нашел открытый процесс и завершил его, пространство было восстановлено.

Связанный контент