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.