O uso do espaço em disco não corresponde ao df & du

Estou tentando liberar espaço em disco - se eu fizer um df -h, tenho um sistema de arquivos chamado / dev / mapper / vg00-var que diz que seu 4G, 3.8G usado e 205M restantes.

Isso corresponde ao meu diretório / var.

Se eu descer para / var e fizer du -kscxh *, o total é 2.1G

2.1G + 200M grátis = 2.3G ... Então, minha pergunta é: onde estão os 1.7G restantes?

linux du df

— Codecraft
fonte

O que du -shx /vardiz?

— Kyle Smith

Você também pode ter arquivos excluídos que possuem identificadores abertos. O sistema operacional não liberará o espaço até que as alças estejam fechadas, mas você não as verá com "du". Você pode executar "lsof / var | grep excluído" (ou algo semelhante) para vê-los. Na verdade, isso não seria uma descoberta surpreendente em, digamos, / var / log, se os logs forem rotacionados, mas o processo de log não estiver no HUP da maneira correta.

— Cjc

Eu estava excluindo alguns arquivos de log que ficaram loucos, parecia que eles não estavam girando, mas de qualquer maneira, eu recebi um e-mail de uma palavra de um amigo 'reboot' - achei que ele estava sendo sarcástico, mas aparentemente não :) I encontrei meu espaço em disco novamente .... desastre evitado (por enquanto).

— Codecraft

@Codecraft Sim, a reinicialização definitivamente limpará qualquer identificador de arquivo aberto, embora seja como quebrar um ovo com um martelo.

— cjc

@cjc, desde que eu receba a bondade da gema ...! Alguma sugestão sobre como eu poderia limpar identificadores de arquivos abertos sem martelar meu ovo?

— Codecraft

Você provavelmente tem algum grande arquivo de log excluído, arquivo de banco de dados ou algo semelhante, aguardando o processo que contém o arquivo que está sendo liberado.

No Linux, uma exclusão de arquivo simplesmente desassocia o arquivo. Na verdade, ele é excluído quando não há mais identificadores de arquivos conectados a ele. Portanto, se você tiver um arquivo de log de 2 GB que você excluir manualmente com rm, o espaço em disco não será liberado até que você reinicie o daemon syslog (ou envie um HUPsinal para ele).

Experimentar

lsof -n | grep -i deleted

e veja se você tem algum arquivo zumbi excluído ainda flutuando.

— Janne Pikkarainen
fonte

Não comecei a executar seu comando, mas o que você disse pareceu estar errado - eu estava matando manualmente alguns logs que ficaram loucos e, no final, uma reinicialização fez com que o espaço em disco fosse recalculado e exibido corretamente.

— Codecraft

Ele funcionou para nós com os logs do Apache preenchendo o diretório / var / log / apache /. Portanto, talvez você não precise reiniciar o servidor inteiro, nem o syslog, apenas o serviço que encontrará na saída do comando acima.

— Yvan

Só tivemos isso nós mesmos. O tomcat6 catalina.out não foi pego pelo logrotate, o excluímos quando atingiu 4Gb e o logrotate fixo. Semanas depois, nos perguntamos por que o 4Gb não havia voltado. Esse lsofcomando mostrou que havia muitos arquivos tomcat com exclusão pendente. Reiniciando o tomcat e de repente temos toneladas de espaço de volta!

— Nick

Finalmente uma resposta que funcionou para mim. O PostgreSQL travou e deixou conexões abertas para 400GiB (!!!) de arquivos desvinculados em um disco de 1TiB. Reiniciar o Postgres o corrigiu.

— Sudo #