Planteamiento y alcance
La utilización normal de bytes no demuestra que un sistema de archivos pueda crear otro archivo. ext4 y sistemas de archivos similares gestionan bloques de datos e inodos; millones de archivos pequeños, fragmentos de caché, colas de correo o capas de contenedores pueden agotar los inodos primero. La tarea consiste en encontrar la causa mientras el servicio se está ejecutando, sin eliminar un directorio desconocido ni ocultar evidencia con un reinicio.
El material público de entrevistas de Linux y DevOps suele utilizar el "disco lleno" como un escenario de diagnóstico. El manual de df y la documentación de ext4 del kernel de Linux definen los límites entre bloques, inodos y entradas de directorio, por lo que una respuesta sólida deriva acciones a partir de evidencia en lugar de recitar comandos de limpieza.
Qué está evaluando el entrevistador
- Distinguir entre bloques de bytes, inodos, cuotas de usuario/proyecto y capas escribibles de contenedores.
- Confirmar el montaje afectado, la ventana de tiempo y la ruta de escritura antes de tomar medidas.
- Encontrar puntos críticos de archivos pequeños, montajes ocultos, fallas en la rotación y archivos eliminados mientras siguen abiertos.
- Elegir pasos de recuperación reversibles y auditables en lugar de
rm -rfo un reinicio a ciegas. - Monitorear el uso de inodos, el crecimiento del conteo de archivos y los puntos críticos de directorios como señales de capacidad.
Preguntas para aclarar primero
- ¿En qué ruta y montaje escribe el proceso que falla? ¿Es el host, un contenedor o un sistema de archivos temporal?
- ¿Qué reportan
df -hydf -i? ¿Hay cuotas de usuario o de proyecto involucradas? - ¿La falla ocurre al crear un archivo, extenderlo o escribir en overlay, tmpfs o un sistema de archivos de red?
- ¿Se está ejecutando un despliegue, rotación de registros, respaldo o trabajo por lotes? ¿Las reglas de retención restringen la eliminación?
- ¿Se puede regular brevemente el servicio y existe una ventana de reversión o verificación de estado?
Una respuesta de 30 segundos
"Identificaría con precisión el proceso que falla, el montaje y la ventana de tiempo, y luego compararía df -h con df -i. Si el uso de inodos está cerca del 100%, localizaría los puntos críticos en el conteo de archivos e inspeccionaría las capas escribibles de contenedores, la rotación de registros y las cuotas. Si los inodos están en buen estado, verificaría bloques, espacio reservado, cuotas y archivos abiertos eliminados. La recuperación comenzaría con una rotación controlada, compresión, limpieza de datos temporales confirmados o expansión mientras se preserva la evidencia. Por último, configuraría alertas sobre bytes, inodos, conteos de archivos, tasa de crecimiento y tiempo de remediación en lugar de un único porcentaje de disco."
Respuesta a profundidad
Paso 1: Establecer el límite de la falla
Preserva los registros de la aplicación y del kernel, la ruta que falla y la información de montaje. Determina si es un solo servicio, un contenedor o el host el que no puede crear archivos. El mismo texto de error puede representar agotamiento de inodos, bloques, cuotas o un sistema de archivos de solo lectura.
Paso 2: Verificar bloques e inodos en conjunto
df -hT /
df -iT /
findmnt -T /var/lib/appdf -h reporta bloques de datos y df -i reporta inodos. Lee ambos para el montaje al que pertenece la ruta que falla. Si el uso de inodos está cerca del 100% mientras aún quedan bytes, prioriza el análisis de archivos pequeños; si no, inspecciona bloques, cuotas, estado de solo lectura y límites de contenedores.
Paso 3: Localizar puntos críticos de directorios por conteo
Cuenta las entradas de directorio antes de leer el contenido de los archivos para evitar I/O innecesario. Limita la búsqueda por directorio y desciende en la rama de crecimiento más rápido. Acota find a rutas conocidas, excluye otros montajes y asigna un presupuesto de recursos al recorrido durante el tráfico pico. Un directorio lleno de archivos diminutos puede consumir inodos mientras usa poco espacio en bytes.
Paso 4: Separar archivos de los límites de montaje
Los sistemas de archivos overlay, montajes bind, tmpfs y volúmenes de registros pueden hacer que la ruta del host difiera de la capa donde escribe el proceso. Cruza la información del directorio de trabajo del proceso, la configuración del contenedor y findmnt -T. No elimines archivos de la capa del contenedor desde el host; utiliza el runtime, la política de volúmenes o la ruta de limpieza de la aplicación.
Paso 5: Inspeccionar rotación, cachés y archivos abiertos eliminados
La rotación puede renombrar un registro sin obligar al proceso a reabrirlo, y las cachés pueden crear archivos pequeños sin límite. lsof +L1 encuentra archivos con cero enlaces de directorio que un proceso aún mantiene abiertos. Liberarlos normalmente requiere que el propietario cierre o reabra el archivo de forma segura. Un reinicio no es la opción predeterminada porque destruye evidencia y puede reproducir la tormenta de escrituras.
Paso 6: Elegir una acción de recuperación
Ordena las acciones por riesgo: regula los productores no críticos, rota o comprime registros confirmados, limpia cachés cubiertas por la política de retención, y luego expande o migra. Registra cada ruta, tamaño, conteo de archivos, propietario y plan de reversión. Antes de eliminar, verifica que los datos no sean configuración actual, estado de colas, material de bases de datos o evidencia de auditoría.
Paso 7: Verificar la recuperación y los efectos secundarios
Ejecuta df -hT y df -iT nuevamente, luego realiza una creación real de archivo temporal, una escritura de registro y una solicitud crítica. Confirma que el uso de inodos, la tasa de errores y la latencia se recuperen. Para contenedores, verifica que reconstruir o reiniciar no vuelva a generar inmediatamente el pico en el conteo de archivos.
Paso 8: Construir defensas duraderas
Monitorea el uso de bloques e inodos, archivos por montaje, crecimiento de directorios, retraso en la rotación, archivos abiertos eliminados y el tamaño de la capa del contenedor. Establece umbrales a partir de la tasa de crecimiento y el tiempo de respuesta, no a partir de un número universal del 90%. Coloca la limpieza, expansión, recuperación de rotación y verificación en un runbook ejecutable y ensáyalo.
Compensaciones y límites
Limpieza frente a expansión
La limpieza restablece el servicio rápidamente pero el problema puede reaparecer; la expansión añade margen sin corregir el generador. Restaura primero y luego usa la evidencia de crecimiento para elegir entre cambios en la aplicación, rotación, granularidad de archivos o expansión.
Precisión de la medición frente a costo en línea
Un find de todo el disco es preciso pero costoso. Los conteos de directorios y el muestreo se adaptan bien al monitoreo continuo. Durante un incidente, reduce el alcance progresivamente en lugar de leer recursivamente todo el sistema de archivos bajo presión de I/O.
Host frente a contenedor
Las métricas del host no reemplazan las métricas de volúmenes y de overlay. Cada capa escribible necesita una cuota, un propietario y un límite de limpieza; la eliminación entre capas puede generar un comportamiento impredecible de imágenes o volúmenes.
Simulacros de fallas y evolución
Falla: mirar únicamente df -h
Pueden quedar bytes libres mientras los inodos están en cero. Incluye df -i en los diagnósticos de primera respuesta y en el historial de alertas por montaje.
Falla: rm -rf al directorio más grande
Podría contener colas, evidencia o archivos en proceso de escritura. Confirma la propiedad, retención, descriptores abiertos y reversión, y luego limpia en lotes acotados.
Falla: reiniciar en lugar de recuperar
Un reinicio puede liberar temporalmente archivos abiertos eliminados mientras destruye evidencia y oculta el generador. Permite que el propietario cierre los archivos de manera segura y verifica la siguiente escritura.
Errores comunes y preguntas de seguimiento
Error: el uso de inodos depende únicamente del tamaño del archivo
Los inodos se consumen principalmente por el conteo de archivos y el formato del sistema de archivos; los archivos de cero bytes y los diminutos aún los consumen.
Pregunta de seguimiento: ¿por qué eliminar un archivo no liberó espacio?
El proceso todavía mantiene su descriptor de archivo. La entrada de directorio desapareció, pero los bloques y el inodo permanecen asignados hasta que se cierre el descriptor.
Pregunta de seguimiento: ¿cómo distinguir las cuotas?
Compara las métricas de todo el sistema de archivos con las cuotas de usuario, proyecto y contenedor, y luego ejecuta una prueba de creación controlada con la misma identidad en la misma ruta.
Pregunta de seguimiento: ¿cómo validar la rotación de registros?
Verifica que el proceso abra el nuevo archivo, cierre el descriptor antiguo y que el conteo de archivos y el uso de inodos caigan dentro del presupuesto; un nuevo nombre de archivo por sí solo no es prueba suficiente.
Pregunta de seguimiento: ¿cómo prevenir una tormenta de archivos pequeños?
Agrupa registros por lotes, particiona por tiempo, limita las entradas de caché, establece límites de rotación y monitorea la tasa de creación de archivos y el crecimiento de entradas de directorio.
Pregunta de seguimiento: ¿cuándo no ayuda la expansión?
Si la densidad de inodos es fija y el nuevo sistema de archivos proporciona el mismo diseño de inodos, agregar bytes no soluciona el agotamiento de inodos. Migra, reconstruye o cambia la granularidad de los archivos.