df diz que o disco está cheio, mas não está

Em um servidor virtualizado executando o Ubuntu 10.04, o df reporta o seguinte:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.4G  7.0G     0 100% /
none                  498M  160K  498M   1% /dev
none                  500M     0  500M   0% /dev/shm
none                  500M   92K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  500M     0  500M   0% /lib/init/rw
/dev/sda3             917G  305G  566G  36% /home

Isso está me intrigando por dois motivos: 1.) O df diz que / dev / sda1, montado em /, possui uma capacidade de 7,4 gigabytes, dos quais apenas 7,0 gigabytes estão em uso, mas informa que está 100% cheio; e 2.) Eu posso criar arquivos em / para que claramente tenha espaço restante.

Possivelmente relevante é que o diretório / www seja um link simbólico para / home / www, que esteja em uma partição diferente (/ dev / sda3, montada em / home).

Alguém pode oferecer sugestões sobre o que pode estar acontecendo aqui? O servidor parece estar funcionando sem problemas, mas quero garantir que não haja um problema com a tabela de partições, os sistemas de arquivos ou qualquer outra coisa que possa resultar em implosão (ou explosão) posteriormente.

É possível que um processo tenha aberto um arquivo grande que já foi excluído. Você terá que matar esse processo para liberar espaço. Você pode identificar o processo usando lsof. No Linux, os arquivos excluídos e abertos são conhecidos por lsof e marcados como (excluídos) na saída de lsof.

Você pode verificar isso com sudo lsof +L1

5% (por padrão) do sistema de arquivos é reservado para os casos em que o sistema de arquivos é preenchido para evitar problemas sérios. Seu sistema de arquivos está cheio. Nada de catastrófico está acontecendo devido ao buffer de 5% - o root pode usar esse buffer de segurança e, na sua configuração, os usuários não raiz não têm motivos para gravar nesse sistema de arquivos.

Se você tiver daemons que são executados como um usuário não raiz, mas que precisam gerenciar arquivos nesse sistema de arquivos, as coisas vão quebrar. Um daemon comum é esse named. Outro é ntpd.

Você pode estar sem inodes. Verifique o uso do inode com este comando:

df -i

A maioria dos sistemas de arquivos Linux reserva 5% de espaço para usar apenas o usuário root.

Você pode ver isso com, por exemplo

dumpe2fs /dev/sda1 | grep -i reserved

Você pode alterar o valor reservado usando:

tune2fs -m 0 /dev/sda1

Na maioria dos casos, o servidor continuará funcionando bem - supondo que todos os processos estejam sendo executados como 'root'.

Eu tive esse problema e fiquei perplexo com o fato de excluir vários arquivos grandes não melhorar a situação (não sabia sobre o buffer de 5%) de qualquer maneira, seguindo algumas dicas aqui

De raiz percorreu os maiores diretórios revelados fazendo repetidamente: -

du -sh */ 

até que eu vim um diretório para arquivos de log do servidor da web que tinham alguns logs absolutamente enormes

que eu truncou

:>lighttpd.error.log

de repente df -h caiu para 48% usado!

Além das causas já sugeridas, em alguns casos, também pode ser o seguinte:

• um disco diferente é montado "sobre" a pasta existente cheia de dados
• du irá calcular o tamanho gasto do disco montado e o df mostrará realmente o gasto
• solução: (quando possível) desmonte todos os discos não raiz e verifique o tamanho du -md 1novamente. Corrija a situação movendo a pasta oculta para outro local ou monte em outro local.

df -hestá arredondando os valores. Até as porcentagens são arredondadas. Omita -he você vê diferenças mais refinadas.

Oh. E ext3 e derivados reservam uma porcentagem (padrão 5%) para o sistema de arquivos exatamente para esta constelação problemática. Se o seu sistema de arquivos raiz estiver realmente cheio (0 byte restante), você não poderá inicializar o sistema. Portanto, a parte reservada evita isso.

Fiz uma grande atualização de várias bibliotecas e havia muitas bibliotecas e arquivos temporários desnecessários, então libertei espaço na pasta "/" usando:

apt-get install -f
sudo apt-get clean

E esvazie seu lixo

verifique o / lost + found, eu tinha um sistema (centos 7) e alguns arquivos no / lost + found consumiram todo o espaço

Se sua partição for btrfs, pode haver um subvolume ocupando espaço. Um sistema de arquivos btrfs pode ter muitos subvolumes, apenas um dos quais está montado. Você pode usar btrfs subvolume list <dir>para listar todos os subvolumes e btrfs subvolume delete <dir>/<subvolume>excluir um. Certifique-se de não excluir o que está montado por padrão.