Eu tenho um servidor de arquivos em que o df reporta 94% de / full. Mas de acordo com du, muito menos é usado:
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 270G 240G 17G 94% /
# du -hxs /
124G /
Eu li que arquivos abertos, mas excluídos, podem ser responsáveis por isso, mas uma reinicialização não corrigiu isso.
Este é o Linux, ext3.
considera
Ok, achei.
Eu tinha um backup antigo em / mnt / Backup no mesmo sistema de arquivos e, em seguida, uma unidade externa montada naquele local. Então du não viu os arquivos. Então, limpar isso me devolveu meu espaço em disco.
Provavelmente aconteceu desta forma: a unidade externa foi desmontada enquanto o script de backup diário era executado.
Eu não acho que você encontrará uma explicação mais completa que este link por todas as razões pelas quais ele poderia estar desligado. Alguns destaques que podem ajudar:
Qual é o seu uso do inode, se é quase 100% que pode atrapalhar as coisas:
df -i
Qual é o tamanho do seu bloco? Muitos arquivos pequenos e um grande tamanho de bloco podem distorcer bastante isso.
sudo tune2fs -l / dev / sda1 | grep 'Tamanho do bloco'
Arquivos apagados, você disse que investigou isso, mas para obter o espaço total você pode usar o seguinte pipeline (eu gosto de encontrar em vez de lsof só porque lsof é difícil de analisar):
sudo find / proc / * / fd-printf "% l \ t% s \ n" | grep excluído | corte -f2 | (tr '\ n' +; echo 0) | bc
No entanto, isso é quase 2x de folga. Execute fsck na partição enquanto ela está desmontada para ser segura.
Parece um caso de arquivos sendo removidos enquanto os processos ainda os abrem. Essa desconexão ocorre porque o comando du totaliza o espaço dos arquivos que existem no sistema de arquivos, enquanto o df mostra os blocos disponíveis no sistema de arquivos. Os blocos de um arquivo aberto e excluído não são liberados até que o arquivo seja fechado.
Você pode descobrir quais processos têm arquivos abertos, mas excluídos, examinando / proc
find /proc/*/fd -ls | grep deleted
O motivo mais provável no seu caso é que você tem muitos arquivos que são muito pequenos (menores que o tamanho do bloco na unidade). Nesse caso, df reportará a soma de todos os blocos usados, enquanto du informará a soma real dos tamanhos dos arquivos.
Concordo que
lsof +L 1 /home | grep -i deleted
é um bom lugar para começar, no meu caso eu percebo que eu tinha muitos scripts perl que estavam rodando e mantendo muitos arquivos vivos, mesmo que eles fossem deletados.
Eu matei as funções perl, e isso tornou du e df quase idênticas, caso encerrado.
Por padrão, quando você formata um sistema de arquivos com EXT3, 5% da unidade é reservada para root. df considera essa reserva quando relata o que está disponível, enquanto du mostra o que está realmente em uso.
Você pode ver os blocos reservados executando:
tune2fs -l /dev/sda|grep -i reserve
e você terá algo como:
Reserved block count: 412825
Reserved GDT blocks: 1022
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
Se você quiser ajustar isso para um percentual mais baixo, poderá fazer isso com algo como
tune2fs -m 1 /dev/sda
Você pode reduzi-lo a 0, mas como esse é o seu sistema de arquivos raiz, eu ficaria desconfiado em fazer isso. Se o sistema de arquivos realmente for preenchido, pode ser difícil executar as tarefas de manutenção necessárias para limpá-lo.
É possível que talvez du não inclua o tamanho dos diretórios também? Ainda assim, parece uma enorme diferença, que não pode ser responsável por tudo isso.