Início / server / Perguntas / 275206
Accepted
initall
Asked: 2011-05-31 04:29:48 +0800 CST

Disco cheio, du diz diferente. Como investigar melhor?

  • 772

Eu tenho um disco SCSI em um servidor (hardware Raid 1), 32G, sistema de arquivos ext3. dfme diz que o disco está 100% cheio. Se eu excluir 1G, isso é 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? lsofnão me mostra nenhum arquivo excluído aberto, lost+foundestá vazio e não há uma instrução óbvia de aviso/erro/falha no arquivo de mensagens.

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

linux disk-space-utilization ext3 scsi

18 respostas

  1. Acabei de tropeçar nesta página ao tentar rastrear um problema em um servidor local.

    No meu caso o df -he du -shincompatível por 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 então resolvida reiniciando o apache ( service httpd restart), e liberou 2 GB de espaço em disco, permitindo que os bloqueios dos arquivos excluídos fossem limpos.

    • 156
  2. Best Answer

    Verifique se há arquivos localizados nos pontos de montagem. Frequentemente, se você monta um diretório (digamos, um sambafs) em um sistema de arquivos que já tinha um arquivo ou diretórios, você perde a capacidade de ver esses arquivos, mas eles ainda estão consumindo espaço no disco subjacente. Eu tive cópias de arquivos enquanto no modo de usuário único despeja 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 em cima deles).

    • 124

  3. Concordo com a resposta do 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 local em 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 está consumindo seu espaço.

    • 84

  4. 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.

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

    • 32

  5. 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 usa todos os inodes disponíveis sem consumir todo o espaço disponível.

    • 30

  6. Os arquivos que são abertos por um programa não desaparecem (param 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 consegue ver. Se for um programa zumbi, talvez seja necessário reiniciar para limpar esses arquivos.

    • 9

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

    • 9

  8. Tente isto para ver se um processo morto/travado está bloqueado enquanto ainda está gravando no disco: lsof | grep "/mnt"

    Em seguida, tente eliminar quaisquer PIDs que estejam presos (especialmente procure por linhas que terminam em "(excluído"))

    • 5

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

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

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

    ls | xargs du -hs

    Saída de exemplo:

    Compartimento de 9,4 milhões
 63M de inicialização
 4,0K cgrupo
 680 mil desenvolvedores
 31M etc
 casa 6.3G
 313M lib
 32M lib64
 16K perdidos+achados
 mídia 61G
 4,0 mil minutos
 113 milhões de opções
 du: não pode acessar `proc/6102/task/6102/fd/4': Nenhum arquivo ou diretório
 0 processo
 raiz de 19 milhões
 corrida de 840K
 19 milhões de unidades
 4.0K selinux
 4,0K srv
 loja 25G
 26M tmp

    então você notaria que a loja é grande faça um cd /store

    e correr novamente

    ls | xargs du -hs

    Saída de exemplo:
 backup de 109 milhões
 358 milhões de fnb
 4.0G iso
 8,0 mil km
 16K perdidos+achados
 raiz de 47 milhões
 11 milhões de roteiros
 79M tmp
 21G vms

    neste caso, o diretório vms é o devorador de espaço.

    • 5

  10. 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 está usando montagens de volume. No caso de um diretório montado em um volume no host docker, df relatará os totais df do HOST. Isso é óbvio se você pensar sobre isso, mas quando você receber um relatório de um "contêiner descontrolado enchendo o disco!", certifique-se de verificar o consumo de espaço no arquivo do contêiner com algo como du -hs <dir>.

    • 2

relate perguntas