Hoy me encontré con este problema en un cuadro de FreeBSD. El problema era que era un artefacto de vi
(no vim
, no estoy seguro si vim
crearía este problema). El archivo consumía espacio pero no se había escrito completamente en el disco.
Puede verificar eso con:
$ fstat -f /path/to/mount/point |sort -nk8 |tail
Esto examina todos los archivos abiertos y los ordena (numéricamente -n
) en la octava columna (clave, -k8
), que muestra los últimos diez elementos.
En mi caso, la entrada final (más grande) se veía así:
bob vi 12345 4 /var 97267 -rwx------ 1569454080 rw
Esto significaba que el proceso (PID) 12345 consumía 1.46G (la octava columna dividida por 1024³) de disco a pesar de la falta de du
notarlo. vi
es horrible al ver archivos extremadamente grandes; incluso 100 MB es grande para ello. 1.5G (o por grande que sea ese archivo) es ridículo.
La solución era sudo kill -HUP 12345
(si eso no funcionara, sudo kill 12345
y si eso también falla, lo temido kill -9
entraría en juego).
Evite los editores de texto en archivos grandes. Ejemplos de soluciones para el desnatado rápido:
Suponiendo longitudes de línea razonables:
{ 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 -
Asumiendo líneas irrazonablemente grandes:
{ head -c8000 big.log; tail -c8000 big.log } |vim -R -
Estos se usan vim -R
en lugar de view
porque vim
casi siempre es mejor ... cuando está instalado. Siéntase libre de colocarlos en su lugar view
o en su vi -R
lugar.
Si va a abrir un archivo tan grande para editar en realidad, considerar sed
o awk
o algún otro enfoque programático.