df Dice que su disco está lleno al 80%, pero du Digamos que solo usaste la mitad, entonces uno de ellos miente, y probablemente no sea lo que piensas.
Está depurando una alarma de disco lleno a las 2 a.m. y el comando df se muestra en rojo mientras du / Regresó luciendo bien. Ejecutas estos dos comandos 3 veces, pensando que has leído mal algo. Los números no coinciden y ahora estás dudando de tu terminal.
Esto sucede con más frecuencia de lo que cabría esperar en sistemas Linux de producción y, por lo general, solo se necesitan 2 comandos para solucionarlo una vez que comprende lo que realmente está sucediendo.
Aquí está el truco:
dfVerifique el uso real del sistema de archivos en el propio disco.duSólo se cuentan los archivos y directorios actualmente visibles.
Entonces, si un proceso elimina un archivo de registro enorme pero aún lo deja abierto, du Ya no verás el archivo, pero df El espacio utilizado todavía se calcula.
Otras razones comunes:
- Bloques del sistema de archivos reservados
- Ocultar punto de montaje
- Abrir archivos eliminados
- Peculiaridades del sistema de archivos de anulación o contenedor
Los números parecen incorrectos, pero ambos comandos son técnicamente correctos, simplemente miden el uso del disco de diferentes maneras.
¿Qué miden realmente df y du?
df El uso del disco se lee directamente desde los metadatos del sistema de archivos, que verifican el superbloque del sistema de archivos para rastrear la cantidad de bloques de disco asignados y la cantidad de bloques de disco libres. No escanea directorios ni inspecciona archivos individualmente.
Simplemente le pregunta al núcleo:
«¿Cuántos bloques del sistema de archivos están actualmente marcados como usados?»
El comando du funciona de manera muy diferente, ya que recorre el árbol de directorios comenzando en la ruta que usted especifica, verificando cada archivo y directorio accesible y sumando sus tamaños.
Entonces cuando ejecutas:
du -sh /
Solo cuenta los archivos que todavía existen en la estructura del directorio.
Por eso a veces los números no coinciden.
Si se elimina un archivo pero un proceso en ejecución todavía lo tiene abierto, el bloque del sistema de archivos permanece asignado y df Aún verás que estos bloques se utilizan porque el kernel aún no los ha liberado.
pero du El archivo ya no se puede ver porque su entrada de directorio ha desaparecido.
Desde la perspectiva del sistema de archivos, el espacio todavía está ocupado. Desde la perspectiva del árbol de directorios, el archivo ya no existe.
Esta es la brecha que ves df y du.
Razón real: los archivos eliminados permanecen abiertos
razones más comunes df y du No estoy de acuerdo es un archivo que se ha eliminado pero aún está abierto.
Cuando un proceso abre un archivo y lo elimina usando el comando rm, Linux no libera espacio en el disco de inmediato. En cambio, elimina la entrada del directorio, por lo que el archivo desaparece de la vista del sistema de archivos. es por eso du Nunca más visto.
Pero los datos siguen ahí.
Si el proceso aún mantiene el archivo abierto, el núcleo conservará los bloques de disco subyacentes asignados. Desde una perspectiva de Linux, estos datos todavía están en uso.
Entonces ahora tienes esta realidad dividida:
- du deja de contar inmediatamente porque el archivo ha «desaparecido» del árbol de directorios.
dfTodavía se calcula porque los bloques del sistema de archivos todavía están asignados.
Un ejemplo muy común de la vida real son los archivos de registro.
La aplicación sigue escribiendo en el archivo de registro, puede eliminarlo usando el siguiente comando rm Se libera espacio y parece que todo se ha limpiado, pero el proceso nunca cierra el descriptor de archivo, por lo que sigue escribiendo en archivos que ya no tienen nombre.
resultado:
duMuestra una caída en el uso del discodfNo muestra cambios- Tu disco todavía parece lleno
El espacio solo se libera cuando el proceso cierra el archivo o se reinicia, porque entonces el núcleo finalmente elimina la última referencia y libera el fragmento.
Este es el más común «Uso de disco invisible”Problema en sistemas Linux de producción.
Si las cifras de uso de su disco parecen completamente incorrectas después de una limpieza de registros o la eliminación de un archivo grande, es casi seguro que esto es lo que sucedió. [share]Comparte este contenido con tu equipo.[/share] Antes de que alguien empiece a eliminar archivos aleatorios y a intentar recuperar el espacio que se ha «desaparecido».
Cómo encontrar el proceso culpable
La herramienta que necesita es lsof, que enumera los descriptores de archivos abiertos en todo el sistema. bien
Para capturar archivos eliminados pero aún abiertos, puede utilizar:
sudo lsof +L1
Esto filtra archivos con un recuento de enlaces inferior a 1, lo que generalmente significa que el archivo se ha eliminado pero aún está abierto por un programa en ejecución.
este sudo Es importante aquí porque sin él, lsof Sólo se muestran los archivos abiertos por el usuario actual. Esto significa que se perderá la mayoría de los servicios del sistema, demonios y cargas de trabajo de producción, que a menudo son la causa real de los problemas de disco.
Si lo ejecutas sin sudo y ver resultados incompletos o lagunas relacionadas con los permisos, ese es el motivo.
El resultado típico se muestra a continuación:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME nginx 1423 root 10w REG 253,1 524288000 0 1048 /var/log/nginx/access.log (deleted) java 2201 tomcat 22w REG 253,1 209715200 0 2341 /tmp/app.log (deleted)
este (deleted) La etiqueta al final confirma que el archivo no tiene entradas de directorio. este SIZE/OFF La columna le indica exactamente cuánto espacio todavía ocupa. En esta salida, nginx sesión 500MB no puedes ver pero df Todos los cálculos se han completado.
Una vez que se identifica el proceso, la solución suele ser reiniciarlo o forzarlo a cerrar el identificador de archivo, lo que libera espacio inmediatamente.
Cómo liberar espacio sin reiniciar
Tienes dos opciones aquí. Uno está limpio y el otro es lo que usas si la producción se incendia y no puedes reiniciar nada.
Opción 1: reiniciar el proceso que mantuvo abierto el archivo
Esta es la solución más segura y confiable.
sudo systemctl restart nginx
Cuando el servicio se reinicia, cierra todos los descriptores de archivos abiertos, luego el kernel libera los bloques del disco y df El espacio liberado se refleja inmediatamente.
Utilice esta función siempre que:
- El servicio tolera reinicios.
- Quiere una recuperación limpia y predecible
- no quieres arriesgarte a tocar
/proc
Opción 2: truncar el archivo mediante /proc
Este es el método de rescate «sin tiempo de inactividad».
de ti lsof salida, captura PID y FDy luego truncar directamente a través del descriptor del archivo de proceso:
sudo truncate -s 0 /proc/1423/fd/10
Qué hace esto:
truncate -s 0Establezca el tamaño del archivo en cero./proc/1423/fd/10Apunta a un archivo que ya está abierto en el proceso en ejecución.
Verifique los resultados.
df -h /var/log
Ejemplo de salida:
Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 18G 30G 38% /
El espacio es inmediatamente evidente. El proceso continúa ejecutándose con su descriptor de archivo abierto, simplemente no queda nada en el archivo.
advertir: No truncar /proc En el registro de escritura anticipada de la base de datos o en cualquier archivo utilizado por el proceso para la recuperación de fallos. Corromperás los datos. Esta técnica es segura para los archivos de registro de aplicaciones normales, ya que es aceptable que falte contenido.
df, du, lsof, tune2fsy una completa cadena de herramientas de almacenamiento con ejemplos prácticos.¿Qué herramienta es adecuada para qué situación?
| Condición | Orden |
|---|---|
| ¿Mi sistema de archivos está realmente lleno? | df -h |
| ¿Para qué se utiliza todo el espacio en este directorio? | du -sh * | sort -rh |
| ¿Por qué no se libera espacio después de eliminar archivos? | lsof +L1 |
| ¿Cuánto espacio utilizan realmente los archivos dispersos? | du -sh (No --apparent-size) |
| ¿Cuánto espacio reserva el sistema de archivos? | tune2fs -l /dev/sdX |
en conclusión
Ahora sabes por qué df y du Darte diferentes números. df Leer asignaciones de bloques del sistema de archivos a nivel central, du Atravesar el árbol de directorios crea un espacio para cualquier cosa en el nivel de bloque que no tenga una entrada de directorio.
Los archivos eliminados pero abiertos son la causa más común y lsof +L1 es la forma más rápida de encontrar espacio para ocupar.
La próxima vez que te encuentres con esto, ejecuta lsof +L1 | sort -k7 -rn Ordene por tamaño de archivo en orden descendente y vaya directamente a los infractores más importantes. Nueve de cada diez veces este es un archivo de registro en el que el demonio todavía está escribiendo después de que alguien lo elimina pensando que ha liberado espacio.
¿alguna vez has df y du no acepte exceder 10GB ¿En un sistema que crees que entiendes? ¿Cuál es la causa? Déjalo en los comentarios, los casos extremos siempre son más interesantes que los comunes..
