Disco cheio, du diz diferente. Como investigar mais?

Eu tenho um disco SCSI em um servidor (hardware RAID 1), 32G, ext3 filesytem. dfdiz-me que o disco está 100% cheio. Se eu excluir 1G, isso será mostrado corretamente.

No entanto, se eu executar um, du -h -x /então dume diz que apenas 12G são usados ​​(eu uso -xpor causa de algumas montagens do Samba).

Portanto, minha pergunta não é sobre diferenças sutis entre os comandos du e df, mas sobre como posso descobrir o que causa essa enorme diferença?

Eu reiniciei a máquina para um fsck que foi sem erros. Devo correr badblocks? lsofmostra que não há arquivos excluídos abertos, lost+foundestá vazio e não há uma declaração óbvia de aviso / erro / falha no arquivo de mensagens.

Sinta-se à vontade para solicitar mais detalhes da configuração.

Verifique se há arquivos localizados nos pontos de montagem. Freqüentemente, se você montar um diretório (digamos, sambafs) em um sistema de arquivos que já possui um arquivo ou diretórios, você perde a capacidade de vê-los, mas eles ainda estão consumindo espaço no disco subjacente. Eu tive cópias de arquivos no modo de usuário único, despejando arquivos em diretórios que eu não conseguia ver, exceto no modo de usuário único (devido a outros sistemas de diretórios sendo montados sobre eles).

Só encontrei esta página ao tentar localizar um problema em um servidor local.

No meu caso, df -he du -shincompatível com cerca de 50% do tamanho do disco rígido.

Isso foi causado pelo apache (httpd) mantendo grandes arquivos de log na memória que foram excluídos do disco.

Isso foi rastreado, executando lsof | grep "/var" | grep deletedonde /varestava a partição que eu precisava limpar.

A saída mostrou linhas como esta:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

A situação foi resolvida reiniciando o apache ( service httpd restart) e limpando 2 GB de espaço em disco, permitindo que os bloqueios nos arquivos excluídos fossem limpos.

Concordo com a resposta do OldTroll como a causa mais provável para o seu espaço "ausente".

No Linux, você pode remontar facilmente toda a partição raiz (ou qualquer outra partição) para outro local do seu sistema de arquivos, digamos / mnt por exemplo, basta emitir um

mount -o bind / /mnt

então você pode fazer um

du -h /mnt

e veja o que ocupa seu espaço.

Ps: desculpe por adicionar uma nova resposta e não um comentário, mas eu precisava de alguma formatação para que este post fosse legível.

Veja o que df -idiz. Pode ser que você esteja sem inodes, o que pode acontecer se houver um grande número de arquivos pequenos nesse sistema de arquivos, que consome todos os inodes disponíveis sem consumir todo o espaço disponível.

No meu caso, isso tinha a ver com grandes arquivos excluídos. Foi bastante doloroso resolver antes de encontrar esta página, que me colocou no caminho correto.

Finalmente resolvi o problema usando lsof | grep deleted, o que me mostrou qual programa estava mantendo dois arquivos de log muito grandes (totalizando 5 GB da minha partição raiz de 8 GB disponível).

Os arquivos abertos por um programa na verdade não desaparecem (para de consumir espaço em disco) quando você os exclui, eles desaparecem quando o programa os fecha. Um programa pode ter um arquivo temporário enorme que você (e você) não pode ver. Se for um programa zumbi, talvez seja necessário reiniciar para limpar esses arquivos.

Tente isso para verificar se um processo morto / travado está bloqueado enquanto ainda está gravando no disco: lsof | grep "/ mnt"

Em seguida, tente eliminar todos os PIDs que estão presos (procure linhas que terminem em "(excluídas"))

Este é o método mais fácil que encontrei até o momento para encontrar arquivos grandes!

Aqui está um exemplo se sua montagem raiz estiver completa / (mount / root) Exemplo:

cd / (então você está na raiz)

ls | xargs du -hs

Saída de exemplo:

 Caixa de 9,4 milhões
 Inicialização de 63 milhões
 4.0K cgroup
 680K dev
 31M etc
 6.3G em casa
 313 milhões de lib
 32M lib64
 16K perdidos + encontrados
 61G media
 4,0K mnt
 113M opt
 du: não pode acessar `proc / 6102 / task / 6102 / fd / 4 ': esse arquivo ou diretório não existe
 0 proc
 Raiz de 19 milhões
 840K run
 19M sbin
 4,0K selinux
 4.0K srv
 Loja 25G
 26M tmp

então você notaria que a loja é grande, faça um CD / loja

e corra novamente

ls | xargs du -hs

Exemplo de saída: 
 Backup de 109 milhões
 358M fnb
 4.0G iso
 8.0K ks
 16K perdidos + encontrados
 47 milhões de raiz
 Scripts de 11 milhões
 79M tmp
 21G vms

neste caso, o diretório vms é o porco do espaço.

Para mim, eu precisava executar, sudo dupois havia uma grande quantidade de arquivos docker sob os /var/lib/dockerquais um usuário não sudo não tem permissão para ler.

Mais uma possibilidade a considerar - é quase garantido que você verá uma grande discrepância se estiver usando o docker e executar df / du dentro de um contêiner que esteja usando montagens de volume. No caso de um diretório montado em um volume no host da janela de encaixe, o df relatará o total de df do HOST. Isso é óbvio se você pensar a respeito, mas quando receber um relatório de um "contêiner fugitivo enchendo o disco!", Verifique se o consumo de espaço no arquivo do contêiner é parecido com du -hs <dir>.

Então, eu também tive esse problema no Centos 7 e encontrei uma solução depois de tentar várias coisas, como bleachbit e cleaning / usr e / var, apesar de mostrar apenas 7G cada. Ainda mostrava 50G de 50G usados ​​na partição raiz, mas mostrava apenas 9G de uso de arquivo. Rodou um cd do ubuntu ao vivo e desmontou a partição 50G ofensiva, abriu o terminal e executou xfs_check e xfs_repair na partição. Em seguida, remontei a partição e meu diretório perdido + encontrado havia se expandido para 40G. Classifiquei o + perdido encontrado por tamanho e encontrou um arquivo de log de texto 38G para o vapor que, eventualmente, apenas repetia um erro de mp3. Removido o arquivo grande e agora tenho espaço e o uso de meus discos concorda com o tamanho da minha partição raiz. Eu ainda gostaria de saber como fazer com que o registro de vapor não cresça tanto novamente.

se o disco montado for uma pasta compartilhada em uma máquina Windows, parece que o df mostrará o tamanho e o uso de disco de todo o disco do Windows, mas du também mostrará apenas a parte do disco que você tem acesso. (e está montado). portanto, neste caso, o problema deve ser corrigido na máquina Windows.

Aconteceu uma coisa semelhante na produção, o uso do disco foi de 98%. Realizou a seguinte investigação:

a) df -ipara verificar o uso do inode, o uso do inode foi de 6%, portanto, arquivos não muito menores

b) Montagem roote verificação de arquivos ocultos. Não foi possível arquivar nenhum arquivo extra . duos resultados foram os mesmos de antes da montagem.

c) Finalmente, nginxlogs verificados . Ele foi configurado para gravar no disco, mas um desenvolvedor excluiu o arquivo de log diretamente, nginxmantendo todos os logs na memória. Como o arquivo /var/log/nginx/access.logfoi excluído do disco, rmele não estava visível, dumas o arquivo estava sendo acessado nginxe, portanto, ainda era mantido aberto

Eu tive o mesmo problema mencionado neste tópico, mas em um VPS. Portanto, testei tudo o que é descrito neste tópico, mas sem sucesso. A solução foi um contato para suporte com nosso provedor VPS, que realizou um novo cálculo de cota e corrigiu a diferença de espaço de df -he du-sh /.

Encontrei este problema em uma caixa do FreeBSD hoje. O problema era que era um artefato de vi(não vim, não tenho certeza se vimcriaria esse problema). O arquivo estava consumindo espaço, mas não havia sido totalmente gravado no disco.

Você pode verificar isso com:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Ele examina todos os arquivos e classificações abertos (numericamente via -n) pela oitava coluna (chave -k8), mostrando os últimos dez itens.

No meu caso, a entrada final (maior) ficou assim:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Isso significava que o processo (PID) 12345 consumia 1,46 G (a oitava coluna dividida por 1024³) de disco, apesar da falta de dunotá-lo. vié horrível ver arquivos extremamente grandes; até 100 MB é grande para isso. 1.5G (ou por mais grande que esse arquivo tenha sido) é ridículo.

A solução foi: sudo kill -HUP 12345(se isso não funcionasse, eu o faria sudo kill 12345e, se isso também falhar, o temido kill -9entraria em ação ).

Evite editores de texto em arquivos grandes. Soluções alternativas de exemplo para escaneamento rápido:

Supondo comprimentos de linha razoáveis:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Supondo (s) linha (s) irracionalmente grande (s):

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Eles usam vim -Rno lugar do viewporque vimquase sempre são melhores ... quando instalados. Sinta-se à vontade para canalizá-los viewou vi -Rsubstituí- los .

Se você estiver abrindo um arquivo tão grande para realmente editá-lo, considere sedou awkou alguma outra abordagem programática.

verifique se o servidor possui o agente ossec instalado. Ou algum processo está usando os arquivos de log excluídos. No meu tempo atrás era agente ossec.

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