A exclusão de um enorme 500G não libera espaço em disco

Question

Eu tenho um servidor remoto aqui rodando o Ubuntu (Server Edition).

Ontem notei que 100% do meu espaço de disco rígido estava ocupado. Houve um arquivo de log que cresceu cada vez maior, então eu deletei via rm file.foo .

Então eu corri df -h , mas a partição onde o arquivo estava armazenado ainda estava 100% ocupada.

Então, pensei que uma reinicialização poderia ajudar e executar sudo shutdown -r now .

Depois de esperar alguns minutos, não consegui me conectar ao servidor via SSH, então pedi aos caras do data center para reiniciá-lo manualmente.

Isso funcionou e o servidor inicializou.

Então eu corri df -h novamente e agora 80% da partição está ocupada (pelo menos alguma coisa).

Em seguida, eu queria verificar o que requer muito espaço em disco e executei sudo du -h --max-depth 1 / , e o resultado foi:

16K /lost+found
942M    /home
52K /tmp
4.0K    /mnt
236K    /dev
du: cannot access '/proc/17189/task/17189/fd/4': No such file or directory
du: cannot access '/proc/17189/task/17189/fdinfo/4': No such file or directory
du: cannot access '/proc/17189/fd/4': No such file or directory
du: cannot access '/proc/17189/fdinfo/4': No such file or directory
0   /proc
4.0K    /media
4.0K    /opt
4.0K    /srv
32K /root
3.0G    /var
393M    /lib
37M /boot
6.9M    /etc
681M    /usr
4.0K    /selinux
8.0M    /bin
9.0M    /sbin
4.0K    /cdrom
0   /sys
5.0G    /

Como você pode ver na última linha, há apenas 5 GB ocupados (portanto, o arquivo não pode estar na lixeira ou "lost + found") - De jeito nenhum está lá, já que usei o comando rm .

Então, o que há de errado?

Meu palpite pessoal seria que, enquanto o servidor estava reiniciando, estava de alguma forma limpando aquele enorme arquivo de 500GB que eu removi. Forçar a reinicialização manual provavelmente foi interrompido, então só foi possível limpar 20% disso.

Se meu palpite for verdadeiro, o que eu poderia fazer para consertar isso?

Se meu palpite estiver errado, então o que acontece com o meu sistema?

    

Answer 1

Meu primeiro palpite seria que qualquer programa que estivesse escrevendo para file.foo ainda estivesse ativo e mantendo o arquivo aberto: O espaço em disco é "livre" apenas aos olhos do kernel quando a última referência ao inode (arquivo ) está desmarcada e os programas que possuem o arquivo aberto contam como referência. Para o futuro: Quando você mover ou excluir um arquivo de log lembre-se de informar o programa que o utiliza - Se você quiser realmente estar seguro, reinicie o programa em questão.

Desde que você reiniciou, embora isso seja teoricamente impossível - todos os programas deveriam ter sido eliminados, então quaisquer referências que eles possuíssem teriam ido embora também. Isso deixa duas possibilidades que eu posso pensar:

1. Você tem um link físico no arquivo que você não conhece.
   Se esse for o caso, du e df devem concordar com a quantidade de espaço que você está usando no sistema.

2. Seu sistema de arquivos está corrompido. Provavelmente no modo em que um inode tem uma contagem de referência positiva, mas não é apontado por nenhum objeto do sistema de arquivos. Isso é relativamente fácil (embora demorado) para verificar: Na maioria dos sistemas Linux, você pode forçar uma verificação do sistema de arquivos durante a reinicialização, criando um arquivo chamado /forcefsck ( touch /forcefsck as root fará o truque) - e reinicie e aguarde (um tempo!) enquanto o seu sistema varre seus sistemas de arquivos procurando coisas como "perdidos" inodes com contagens de referência complicadas.