El uso del espacio en disco no se suma con df & du

Estoy tratando de liberar algo de espacio en el disco: si hago un df -h, tengo un sistema de archivos llamado / dev / mapper / vg00-var que dice que se usa 4G, 3.8G, quedan 205M.

Eso corresponde a mi directorio / var.

Si desciendo a / var y hago du -kscxh *, el total es 2.1G

2.1G + 200M gratis = 2.3G ... Entonces mi pregunta es, ¿dónde está el 1.7G restante?

linux du df

— Codecraft
fuente

Que du -shx /vardice

— Kyle Smith

También podría haber eliminado archivos que tienen identificadores de archivo abiertos. El sistema operativo no liberará el espacio hasta que se cierren los controladores, pero no los verá con "du". Puede ejecutar "lsof / var | grep deleted" (o algo similar) para verlos. En realidad, esto no sería un hallazgo sorprendente en, digamos, / var / log, si los registros se rotan pero el proceso de registro no está HUP'de la manera correcta.

— cjc

Había estado eliminando algunos archivos de registro que se habían vuelto locos, parecía como si no hubieran estado girando, pero de todos modos, recibí un correo electrónico de una palabra de un amigo 'reiniciar', pensé que estaba siendo sarcástico pero aparentemente no :) he encontrado mi espacio en disco de nuevo ... desastre evitado (por ahora)

— Codecraft

@Codecraft Sí, reiniciar definitivamente borrará todos los identificadores de archivos abiertos, aunque eso es como romper un huevo con un martillo.

— cjc

@cjc siempre y cuando llegue a la bondad de la yema ... ¿Alguna sugerencia sobre cómo podría borrar los identificadores de archivos abiertos sin martillar mi huevo?

— Codecraft

Probablemente haya eliminado algún archivo de registro grande, archivo de base de datos o algo similar, esperando que el proceso que contiene el archivo lo libere.

En Linux, la eliminación de un archivo simplemente desvincula el archivo. En realidad, se elimina cuando ya no hay identificadores de archivos conectados a ese archivo. Por lo tanto, si tiene un archivo de registro de 2 GB que elimina manualmente con rm, el espacio en disco no se liberará hasta que reinicie el demonio syslog (o le envíe una HUPseñal).

Tratar

lsof -n | grep -i deleted

y vea si todavía tiene archivos zombies eliminados flotando.

— Janne Pikkarainen
fuente

No pude ejecutar tu comando, pero lo que dijiste parecía estar explotando: había estado matando manualmente algunos registros que se volvieron locos, y al final, un reinicio hizo que el espacio en disco se recalculara y se mostrara correctamente.

— Codecraft

Nos funcionó con los registros de Apache que llenaban el directorio / var / log / apache /. Por lo tanto, es posible que no tenga que reiniciar todo su servidor, ni syslog, solo el servicio que encontrará en el resultado del comando anterior.

— Yvan

Acabo de tener esto nosotros mismos. Tuvimos el tomcat6 catalina.out para no quedar atrapado por logrotate, ¿lo eliminamos cuando alcanzó 4 Gb y lo arreglamos? Semanas después nos preguntamos por qué los 4 Gb no habían regresado. Ese lsofcomando mostró que teníamos muchos archivos tomcat pendientes de eliminación. ¡Reiniciando Tomcat y de repente tenemos toneladas de espacio de vuelta!

— Nick

Finalmente una respuesta que funcionó para mí. PostgreSQL se bloqueó y dejó conexiones abiertas a 400GiB (!!!) de archivos no vinculados en un disco de 1TiB. Reiniciar Postgres lo arregló.

— sudo