Disco cheio, du diz diferente. Como investigar mais?

93

Eu tenho um disco SCSI em um servidor (hardware Raid 1), 32G, ext3 filesytem. df me diz que o disco está 100% cheio. Se eu deletar 1G isto é mostrado corretamente.

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

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

Eu reiniciei a máquina para um fsck que foi sem erros. Devo executar badblocks ? lsof não mostra arquivos abertos excluídos, lost+found está vazio e não há nenhuma indicação óbvia de aviso / erro / falha no arquivo de mensagens.

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

    
por initall 30.05.2011 / 14:29

16 respostas

89

Verifique se há arquivos localizados abaixo dos pontos de montagem. Freqüentemente, se você monta um diretório (digamos, um sambafs) em um sistema de arquivos que já tenha um arquivo ou diretórios sob ele, você perde a capacidade de ver esses arquivos, mas eles ainda consomem espaço no disco subjacente. Eu tive cópias de arquivo enquanto no modo de usuário único despejo arquivos em diretórios que eu não podia ver, exceto no modo de usuário único (devido a outros sistemas de diretório sendo montado em cima deles).

    
por 30.05.2011 / 14:35
77

Apenas tropecei nessa página ao tentar rastrear um problema em um servidor local.

No meu caso, o df -h e o du -sh não correspondem a cerca de 50% do tamanho do disco rígido.

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

Isso foi rastreado executando lsof | grep "/var" | grep deleted , em que /var era 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 então resolvida reiniciando o apache ( service httpd restart ) e limpou 2gb de espaço em disco, permitindo que os bloqueios nos arquivos excluídos sejam limpos.

    
por 12.03.2014 / 12:10
42

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

No Linux, você pode facilmente remontar toda a partição raiz (ou qualquer outra partição) para outro lugar no sistema de arquivos, por exemplo, / mnt, por exemplo, apenas emita um

mount -o bind / /mnt

então você pode fazer um

du -h /mnt

e veja o que usa 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.

    
por 30.05.2011 / 15:54
23

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

    
por 30.05.2011 / 16:10
17

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

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

    
por 14.11.2014 / 19:15
5

Os arquivos que são abertos por um programa não desaparecem (pare 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 du) não pode ver. Se for um programa zumbi, talvez seja necessário reinicializar para limpar esses arquivos.

    
por 30.05.2011 / 14:51
4

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

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

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

ls | xargs du -hs

Exemplo de saída:

 9.4M   bin
 63M    boot
 4.0K   cgroup
 680K   dev
 31M    etc
 6.3G   home
 313M   lib
 32M    lib64
 16K    lost+found
 61G    media
 4.0K   mnt
 113M   opt
 du: cannot access 'proc/6102/task/6102/fd/4': No such file or directory
 0  proc
 19M    root
 840K   run
 19M    sbin
 4.0K   selinux
 4.0K   srv
 25G    store
 26M    tmp

então você notaria que loja é grande cd / store

e volte a correr

ls | xargs du -hs

Example output: 
 109M   backup
 358M   fnb
 4.0G   iso
 8.0K   ks
 16K    lost+found
 47M    root
 11M    scripts
 79M    tmp
 21G    vms

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

    
por 26.06.2011 / 15:05
3

Tente isso para ver se um processo inativo / suspenso está bloqueado enquanto ainda está gravando no disco: lsof | grep "/ mnt"

Em seguida, tente matar todos os PIDs que estão presos (especialmente procurar por linhas que terminem em "(excluído"))

    
por 26.06.2011 / 12:38
1

Então, eu tive esse problema no Centos 7 e encontrei uma solução depois de tentar um monte de coisas como bleachbit e limpeza / usr e / var, embora eles só mostrassem cerca de 7G cada. Ainda mostrava 50G de 50G usado na partição raiz, mas mostrava apenas 9G de uso de arquivo. Ran um live ubuntu cd e desmontou a partição ofensiva 50G, abriu o terminal e correu xfs_check e xfs_repair na partição. Eu então remontei a partição e meu diretório lost + found expandiu para 40G. Classificou o perdido + encontrado pelo tamanho e encontrou um arquivo de log de texto 38G para vapor que, eventualmente, apenas repetia um erro de mp3. Removido o arquivo grande e agora tenho espaço e o uso de meus discos está de acordo com o tamanho da partição raiz. Eu ainda gostaria de saber como fazer com que o log de vapor não cresça tão grande novamente.

    
por 04.05.2017 / 20:01
0

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

    
por 21.06.2012 / 12:33
0

Mais uma possibilidade a considerar - é quase certo que você verá uma grande discrepância se estiver usando o docker e executar o 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 do docker, o df relatará os totais df do HOST. Isso é óbvio se você pensar nisso, mas quando receber um relatório de um "contêiner fugitivo enchendo o disco!", Certifique-se de verificar o consumo de espaço no arquivo do contêiner com algo como du -hs <dir> .

    
por 06.12.2016 / 00:02
0

Para mim, eu precisava executar sudo du , pois havia uma grande quantidade de arquivos do docker em /var/lib/docker que um usuário que não é sudo não tem permissão para ler.

    
por 09.02.2018 / 12:51
0

Uma coisa semelhante aconteceu conosco na produção, o uso do disco foi de 98%. Fiz a seguinte investigação:

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

b) Montando root e verificando arquivos ocultos. Não foi possível arquivar nenhum arquivo extra . du resultados foram os mesmos que antes de montar.

c) Finalmente, verifiquei nginx logs. Ele foi configurado para gravar em disco, mas um desenvolvedor excluiu o arquivo de log diretamente, fazendo com que nginx mantivesse todos os registros na memória. Como o arquivo /var/log/nginx/access.log foi excluído do disco usando rm , ele não ficou visível usando du , mas o arquivo estava sendo acessado por nginx e, portanto, ainda era mantido aberto

    
por 20.04.2018 / 21:23
0

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

    
por 18.07.2018 / 15:33
0

Eu 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 vim criaria esse problema). O arquivo estava consumindo espaço, mas não foi totalmente gravado no disco.

Você pode verificar isso com:

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

Isso examina todos os arquivos abertos e classifica (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 significa que o processo (PID) 12345 estava consumindo 1,46 G (a oitava coluna dividida por 1024³) de disco, apesar da falta de du percebendo isso. vi é horrível ao visualizar arquivos extremamente grandes; até 100MB é grande para isso. 1.5G (ou quão grande que o arquivo realmente fosse) é ridículo.

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

Evite editores de texto em arquivos grandes. Exemplos de soluções alternativas para skimming rápido:

Supondo tamanhos 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 linha (s) excessivamente grande (s):

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

Eles usam vim -R no lugar de view porque vim é quase sempre melhor ... quando é instalado. Sinta-se à vontade para enviá-los para view ou vi -R .

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

    
por 12.10.2018 / 23:58
-3

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

    
por 23.11.2016 / 23:24