Почему du и df не договариваются о временном хранилище AWS?


0

У меня есть экземпляр Amazon AWS с хранилищем, смонтированным в / dev / xvdb, который является "обычным" / mnt / build_tmp. Это около 70 ГБ (ровно 66 946 696 КБ). Попытка написать к нему, это было очевидно полно. Это казалось маловероятным, поэтому я проверил, и там было около 11 ГБ файлов (согласно 'du'), но / mnt (который содержит только / mnt / build_tmp) был заполнен на 100% (согласно 'df'). Я удалил все файлы (около 6 ГБ), кроме одного (который был большим 5,5 ГБ tar-файла), и теперь у меня есть около 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 ГБ + места на диске.

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

Ответы:


0

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

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

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

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

Как только я обнаружил открытый процесс и убил его, пространство было восстановлено.


lsofпоможет вам найти такие файлы, но, возможно, вы уже разработали это. Некоторые программы делают это так, чтобы в случае сбоя они не оставляли временные файлы. Он также обеспечивает примитивный уровень защиты от взлома. duможет только сосчитать, что могут объяснить записи каталога.
Майкл - sqlbot
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.