Eu não acho que uma "ferramenta de visualização de espaço em disco" possa ajudá-lo nesse caso: o espaço ocupado e visível para essas ferramentas é o mesmo visível para du , apenas essas ferramentas o fazem com mais detalhes. Mas a ferramenta ainda relataria apenas aqueles 8 a 10 GB que você já sabe que são usados, e não relatar onde estão esses vinte gigabytes que estão "ausentes em ação".
Uma possível explicação para um espaço "em extinção" de tais proporções é que ele está em um (ou mais) arquivos deletados .
Se você abrir um arquivo no Unix e, enquanto ainda estiver aberto, deletar (desvincular), ele ainda "existirá", mas ficará visível apenas para o processo que contém o descritor de arquivo, e desaparecer imediatamente assim que o processo terminar, liberando o descritor.
Esta é uma ótima maneira de gerenciar arquivos temporários.
Infelizmente, se o arquivo temporário vazar e os dados forem continuamente adicionados a ele, sem nunca fechar e recriar o arquivo, muito espaço em disco poderá "desaparecer".
Como root, tente:
ls -la /proc/*/fd/* | grep deleted
Os nomes dos arquivos e os IDs do processo informam quais processos estão mantendo o espaço "desvinculado".
Se você puder, é claro que a reinicialização terá o mesmo efeito mais rápido. E alguns processos estão tão entrelaçados no sistema que é realmente melhor reiniciá-los do que terminá-los e gerenciar todos os outros processos e serviços dependentes.
Por exemplo, na minha máquina eu tenho cerca de 25 arquivos, e este
lrwx------ 1 root root 64 May 9 07:45 /proc/732/fd/8 -> /tmp/vmware-root/vmware-usbarb-732.log (deleted)
Eu sei que às vezes cresce no intervalo de vários megabytes. Correndo
vmware-usbarbitrator --kill
vmware-usbarbitrator
pode liberar de zero a 100M de espaço, dependendo de quanto tempo está sendo executado e de quanto eu usei vmplayer .
Automatizando o cheque
Uma maneira de verificar quais arquivos estão ocupando espaço seria verificar seus tamanhos: a maioria dos arquivos desvinculados tem apenas alguns bytes.
Este método usa wc , que é muito ineficiente; provavelmente, abrindo o arquivo, procurando SEEK_END e retornando o valor de ftell() seria muito, muito mais rápido (especialmente em arquivos grandes). Mas seria necessário compilar um pequeno utilitário para fazer isso.
for i in $( ls -la /proc/*/fd/* 2>/dev/null \
| grep deleted \
| sed -e 's/.*\(\/proc\S*\) -.*//g' ); do
wc -c $i | tr "\n" "="; readlink $i
done | grep -v "^0 " | sort -rn
Isso emprega uma forma (esperançosamente) portátil de listar os fd virtuais de todos os arquivos excluídos e os lê com wc . Então, para cada arquivo, lê o link simbólico. Arquivos de comprimento zero são ignorados para evitar confusão.
No meu sistema recém-inicializado, isso me dá
217032 /proc/812/fd/9=/var/run/nscd/dbMn7Auu (deleted)
217032 /proc/812/fd/8=/var/run/nscd/dbMn7Auu (deleted)
3278 /proc/2357/fd/3=/tmp/vmware-root/vmware-apploader-2327.log (deleted)
2257 /proc/2422/fd/7=/tmp/vmware-root/vmware-authdlauncher-2418.log (deleted)
então eu sei que nscd está se aproveitando de 400 Kb de "espaço invisível" (isso não muda se eu reiniciar nscd ; então é provavelmente uma área de trabalho que não cresce ... muito. Nada me impede de acompanhar o processo, no entanto).
Também seria fácil salvar o código acima em um pequeno utilitário e executá-lo em cron , descartando todos os valores em (digamos) 500 megas, mas enviar um e-mail para o administrador deve aparecer algo eventualmente.