Por que du e df não concordam com o armazenamento efêmero da AWS?

Question

Eu tenho uma instância do Amazon AWS com um armazenamento montado em / dev / xvdb, que é o "usual" / mnt / build_tmp. São cerca de 70GB (exatamente 66.946.696kB). Tentando escrever para ele, aparentemente estava cheio. Isso pareceu improvável, então eu verifiquei e havia cerca de 11GB de arquivos nele (de acordo com 'du'), mas / mnt (que contém apenas / mnt / build_tmp) estava 100% cheio (de acordo com 'df'). Eu apaguei todos os arquivos (cerca de 6 GB), exceto um (que era um grande arquivo tar de 5,5 GB) e agora tenho cerca de 6 GB de espaço livre. Precisamente, no momento, esta é a situação:

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

Alguém pode explicar isso? Eu nunca vi nada assim antes. Estou pensando que isso é resultado da AWS, mas pode ser algo mais genérico.

Em qualquer caso, preciso recuperar os 50 GB + de espaço ausentes no disco.

[p.s. Eu já verifiquei a pergunta do superusuário "por que o df é diferente do du", isso não pareceu relevante para o meu problema.]

    

Answer 1

Isso acaba sendo uma variante do problema descrito aqui:

link

A solução descrita aqui foi a solução para este problema.

If a file that has been deleted is still open by a process, the space will not be reclaimed until the process closes the file (or is killed). If you can not identify the process that is holding a file open, then a reboot will help as that will close all running processes (and so close all open files).

Depois de localizar o processo aberto e matá-lo, o espaço foi recuperado.