Entrevista de Linux: ¿Por qué df y du muestran un uso de disco diferente?

Enunciado y contexto aplicable

A las 02:00, una aplicación comienza a recibir ENOSPC mientras escribe bajo /var. El host reporta:

$ df -B1 /var
Filesystem          1B-blocks         Used  Available Use% Mounted on
/dev/nvme0n1p3    214748364800 210453397504          0 100% /var

$ sudo du -x -B1 -s /var
126701535232  /var

$ df -i /var
Filesystem          Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p3    20000000 4200000 15800000   21% /var

Los valores redondeados son 200 GiB en total, 196 GiB usados según df y 118 GiB alcanzables a través de du, lo que deja una brecha de espacio usado de 78 GiB. La salida de inodos descarta el agotamiento de inodos como la causa inmediata. El servicio no tiene privilegios, el host no se puede reiniciar y no se puede eliminar ningún archivo hasta que se conozcan su propietario y propósito.

Esta es una pregunta de resolución de problemas en producción de Linux. La respuesta más sólida no comienza eliminando la ruta más grande. Primero demuestra que ambas herramientas observaron el mismo sistema de archivos, espacio de nombres, tiempo, unidades y alcance de acceso; luego explica qué asignación puede existir fuera del árbol de directorios visible y elige una acción de recuperación cuyo radio de impacto se entienda.

Qué evalúa el entrevistador

La primera señal es un modelo de medición correcto. df consulta a un sistema de archivos montado sus estadísticas globales de bloques. du recorre archivos y directorios con nombre y estima los bloques representados por las entradas que puede alcanzar. Están midiendo conjuntos relacionados pero diferentes. Una asignación grande retenida por un archivo desvinculado u oculta debajo de un directorio sobremontado permanece en el total del sistema de archivos aunque el recorrido actual no pueda nombrarla.

La segunda señal es el control del alcance. Comparar df /var con un du /var sin restricciones, ejecutar un comando dentro de un contenedor, ignorar errores de permisos o comparar muestras tomadas durante escrituras rápidas puede fabricar una discrepancia. Un candidato debe alinear el destino de montaje, el espacio de nombres de montaje, el límite del sistema de archivos, las unidades de bytes, los privilegios y la ventana de observación antes de asignar una causa.

La tercera señal es una respuesta a incidentes segura. lsof +aL1 /var puede identificar archivos abiertos con un conteo de enlaces menor a uno en ese sistema de archivos, pero su salida es evidencia y no una autorización para terminar un proceso o truncar un descriptor. Una respuesta sólida identifica al propietario del servicio, confirma el descriptor de archivo y el dispositivo, prefiere una reapertura de registros admitida por la aplicación o un reinicio ordenado, y verifica tanto la recuperación del disco como el estado de la aplicación.

La cuarta señal es separar causas que parecen similares. Los bloques reservados de ext4 reducen el espacio disponible para los procesos de escritura sin privilegios y pueden hacer que Size - Used exceda a Avail; no explican por qué df contabiliza 78 GiB como usados pero están ausentes en un recorrido de du en el mismo sistema de archivos. El agotamiento de inodos también puede devolver ENOSPC, pero el uso de inodos del 21% del enunciado descarta esa rama. Las instantáneas copy-on-write, la compresión y las cuotas requieren herramientas específicas del sistema de archivos en lugar de un comando ext4 copiado a ciegas.

La señal final es el cierre. La respuesta debe establecer un conjunto de evidencias de antes y después, explicar el rango de bytes recuperado, confirmar que el proceso de escritura reabrió la ruta prevista, verificar que no haya un crecimiento recurrente de archivos eliminados pero abiertos y mejorar la rotación de registros o el monitoreo de cambios de montaje. Un porcentaje más bajo en df por sí solo no demuestra que la aplicación esté en buen estado o que se hayan preservado los datos.

Preguntas para aclarar antes de responder

• ¿Ambos comandos se ejecutan en el mismo espacio de nombres de montaje? Si uno se ejecuta en el host y el otro en un contenedor o espacio de nombres de servicio, /var puede resolverse en montajes diferentes. La investigación debe ingresar al espacio de nombres del proceso afectado o permanecer deliberadamente en el host.
• ¿Qué ruta exacta está fallando y qué sistema de archivos la contiene? findmnt -T mapea una ruta arbitraria a su montaje. Un montaje anidado o bind mount cambia contra qué se deben comparar df y du.
• ¿Se tomaron las muestras juntas con las mismas unidades y privilegios? Los registros de rápido crecimiento pueden cambiar entre comandos, el redondeo legible para humanos oculta diferencias menores y los directorios ilegibles hacen que un du sin privilegios cuente por debajo de lo real.
• ¿Qué sistema de archivos y capas de almacenamiento están involucrados? ext4, XFS, Btrfs, ZFS, sistemas de archivos overlay, instantáneas LVM e instantáneas de volúmenes en la nube exponen diferentes controles de contabilidad y recuperación.
• ¿La escasez es de bloques de datos, inodos o una cuota? df -i, las herramientas de cuotas y el error de la aplicación distinguen las ramas. Eliminar un archivo grande no soluciona el agotamiento de inodos, y los bloques globales libres no anulan una cuota de usuario o proyecto.
• ¿Qué acciones de recuperación están operativamente permitidas? Una señal de reapertura de registros, un reinicio ordenado, una conmutación por error o una breve ventana de mantenimiento tienen diferentes riesgos de disponibilidad. El truncamiento de descriptores de emergencia necesita una propiedad explícita y una planificación de reversión.
• ¿Cuánto margen de maniobra debe restaurarse y para cuándo? El objetivo determina si se deben contener las escrituras, expandir el volumen, conmutar el tráfico o recuperar primero la asignación conocida. No justifica eliminar datos desconocidos.

Estructura de respuesta de 30 segundos

“Primero congelaría las acciones destructivas y compararía la misma ruta, sistema de archivos, espacio de nombres de montaje, tiempo, privilegios y unidades de bytes usando findmnt, df -B1 y sudo du -x -B1. Con el uso de inodos al 21%, cuantificaría la brecha de bloques de 78 GiB y revisaría lsof +aL1 /var en busca de archivos desvinculados que los procesos aún mantienen abiertos. Si uno explica la brecha, verificaría su PID, descriptor, dispositivo y propietario del servicio, luego usaría la ruta de reapertura de registros de la aplicación o un reinicio ordenado y confirmaría que el espacio regresa. Si no, inspeccionaría directorios sobremontados, errores de permisos y metadatos o instantáneas específicos del sistema de archivos. Los bloques reservados de ext4 explican la disponibilidad cero sin privilegios, no la brecha de espacio usado de 78 GiB. Cerraría repitiendo las mediciones y verificando las escrituras de la aplicación, los registros y la recurrencia”.

Análisis paso a paso a profundidad

Comienza haciendo reproducible la comparación. Captura la ruta que falla, el espacio de nombres actual, el origen del montaje, el tipo de sistema de archivos, las estadísticas de bloques, las estadísticas de inodos y el total de du en momentos muy próximos:

readlink -f /var
findmnt -T /var -o SOURCE,FSTYPE,OPTIONS,TARGET
df -B1 /var
df -i /var
sudo du -x -B1 -s /var

-x mantiene a du en el sistema de archivos que contiene a /var, por lo que un sistema de archivos anidado no se suma al total. -B1 elimina la ambigüedad en las unidades de bloques. Ejecuta du con suficientes privilegios y lee sus diagnósticos; suprimir los errores de permisos sin inspeccionarlos convierte un problema de acceso en una teoría de almacenamiento falsa. Captura los comandos desde el mismo espacio de nombres de montaje. Para un proceso de escritura en contenedor, compara la vista del host con una vista deliberada de nsenter en lugar de asumir que cadenas de rutas idénticas nombran objetos idénticos.

La brecha observada es una cantidad de diagnóstico, no un archivo para buscar:

same_filesystem_gap = df_used_blocks - du_reachable_allocated_blocks
                    = 196 GiB - 118 GiB
                    = 78 GiB

Esta ecuación es aproximada porque los metadatos del sistema de archivos, la granularidad de la asignación, las escrituras concurrentes, el uso compartido copy-on-write, la compresión y la semántica de las herramientas no forman una partición perfecta. Aún así es útil: una brecha estable de 78 GiB es demasiado grande para descartarla como un redondeo de salida. Busca causas que asignen bloques fuera del árbol visible y alcanzable antes de buscar otra ruta grande ordinaria.

La comprobación de mayor valor es un archivo abierto cuyo enlace de directorio final ha sido eliminado:

sudo lsof +aL1 /var

# After selecting a candidate from lsof, verify the live descriptor.
sudo readlink /proc/2481/fd/7
sudo stat -Lc 'device=%d inode=%i size=%s blocks=%b block_size=%B' /proc/2481/fd/7

En Linux, unlink elimina un nombre. Si era el enlace final pero un proceso aún tiene el archivo abierto, el archivo y sus bloques permanecen hasta que se cierre el último descriptor que hace referencia a él. du no puede alcanzar ese inodo a través del árbol de directorios; df sigue contando sus bloques asignados. Un escenario común de incidentes es un registrador que continúa escribiendo en un archivo después de que una rotación lo eliminó o renombró incorrectamente.

No trates el valor aparente de SIZE/OFF como una previsión de recuperación exacta para cada archivo disperso o especial. Confirma que el descriptor sea un archivo regular en el dispositivo de destino, que su conteo de enlaces sea cero, qué proceso es su propietario, si todavía está creciendo y si la aplicación tiene una señal de reapertura documentada. Correlaciona varios descriptores grandes si uno solo no representa la mayor parte de los 78 GiB.

El orden de recuperación preferido es la reapertura específica de la aplicación, la recarga ordenada, el reinicio ordenado o conmutación por error y, finalmente, la intervención de emergencia. Una acción admitida de reapertura de registros cierra el descriptor obsoleto y abre la ruta actual sin terminar todo el host. Un reinicio controlado del servicio también lo libera, pero debe respetar las réplicas, la preparación y el trabajo en curso. Enviar SIGKILL primero descarta la ruta de limpieza de la aplicación. Eliminar más nombres no hace nada con un archivo que ya está desvinculado.

Escribir a través de /proc/PID/fd/FD puede recuperar espacio sin detener el proceso, pero es un último recurso. El escritor puede retener un desplazamiento antiguo, crear un espacio disperso (sparse hole) en su siguiente escritura, corromper un formato de aplicación o romper invariantes internos. Úsalo solo después de que el propietario del servicio confirme el descriptor y la semántica de escritura, el tráfico esté contenido, la evidencia esté preservada y exista un plan de recuperación. El runbook genérico nunca debe promocionar el truncamiento de descriptores como la solución predeterminada.

Si lsof no puede explicar la brecha, inspecciona la topología de montaje. Un sistema de archivos montado sobre un directorio no vacío oculta las entradas de directorio subyacentes mientras sus bloques permanecen asignados en el sistema de archivos principal. findmnt revela rutas anidadas, bind mounts y rutas sobremontadas. Durante una acción de mantenimiento aprobada, un montaje bind no recursivo de /var a un destino vacío fuera de /var puede exponer la vista principal subyacente sin desmontar el montaje secundario de producción:

sudo mkdir -p /mnt/var-underlay
sudo mount --bind /var /mnt/var-underlay
sudo du -x -B1 -s /mnt/var-underlay
sudo umount /mnt/var-underlay

Valida este enfoque primero contra el árbol de montaje real; la propagación del espacio de nombres y la política de la plataforma pueden cambiar su efecto. No desmontes un sistema de archivos de producción ocupado solo para inspeccionarlo. Si se encuentran archivos ocultos, identifica a su propietario y los requisitos de retención antes de moverlos o eliminarlos.

A continuación, separa la contabilidad de disponibilidad de la brecha de espacio usado. En ext4, los bloques reservados para procesos con privilegios pueden hacer que los bloques libres brutos no estén disponibles para la aplicación. Inspecciona en lugar de modificar:

source=$(findmnt -n -o SOURCE -T /var)
sudo tune2fs -l "$source" | grep -E 'Block count|Reserved block count|Block size'
sudo du --inodes -x -d1 /var | sort -n

El enunciado tiene 4 GiB entre el total y el usado pero muestra cero como disponible, lo cual es consistente con que algunos bloques libres no estén disponibles para un servicio sin privilegios. Eso explica la falla de escritura inmediata, no por qué df marca 78 GiB más como usados de lo que du puede alcanzar. Reducir la reserva durante un incidente puede eliminar el margen de maniobra previsto para daemons privilegiados y aumentar el riesgo de fragmentación; requiere una decisión de capacidad, no un tune2fs -m 0 reflexivo.

El agotamiento de inodos es otra vía independiente de ENOSPC. Aquí df -i muestra 21%, por lo que no es el desencadenante. Si fuera 100%, usa du --inodes -x para ubicar árboles con un alto conteo de archivos y elimina solo los datos cubiertos por una política de retención. La recuperación de bloques y la recuperación de inodos son objetivos separados.

La contabilidad específica del sistema de archivos va al final. GNU du documenta que el uso compartido copy-on-write, la compresión, los bloques de respaldo y los sistemas de archivos de red pueden hacer que su estimación diverja del consumo del dispositivo. En Btrfs o ZFS, inspecciona subvolúmenes, instantáneas, cuotas y bytes exclusivos frente a referenciados con las herramientas de ese sistema de archivos. En almacenamiento overlay, inspecciona las capas desde el espacio de nombres y el entorno de ejecución que las poseen. No ejecutes herramientas de ext4 contra un origen XFS o Btrfs.

Si los archivos abiertos, los datos ocultos, los errores de acceso, el crecimiento concurrente, la disponibilidad reservada y las funciones del sistema de archivos aún no explican la evidencia, inspecciona los registros del kernel y el estado del sistema de archivos. Una herramienta de reparación no es un atajo de diagnóstico en línea: preserva la evidencia, usa el procedimiento documentado del sistema de archivos y programa cualquier verificación que requiera un volumen desmontado.

Cierra el incidente con el mismo conjunto de evidencias. Repite df -B1, df -i y el du -x -B1 privilegiado; confirma que los bytes recuperados coincidan con la asignación cerrada o eliminada dentro de la sobrecarga esperada; verifica una escritura nueva de la aplicación; confirma que el servicio ahora escribe en el archivo con nombre previsto; y verifica la latencia, los errores, las réplicas y la integridad de los datos. Luego, genera alertas sobre el margen de maniobra de bloques e inodos, el crecimiento de archivos eliminados pero abiertos, las fallas de rotación de registros, los cambios en la topología de montaje y el crecimiento inesperado de instantáneas.

Ejemplo de respuesta de alta calidad

“La diferencia de 78 GiB es plausible porque df y du tienen alcances contables diferentes. df obtiene estadísticas de bloques de todo el sistema de archivos, mientras que du recorre las entradas con nombre que puede alcanzar. Primero demostraría que esta es una brecha real mapeando /var con findmnt, ejecutando ambas herramientas en el espacio de nombres de montaje del servicio afectado, usando unidades en bytes, du -x, privilegios de root y muestras casi simultáneas. Los inodos están solo al 21%, por lo que dejaría de lado esa rama.

Mi primera hipótesis son los archivos eliminados pero abiertos. Ejecutaría lsof +aL1 /var y luego verificaría el PID, descriptor de archivo, dispositivo, inodo, propietario y crecimiento de cada resultado grande. Si un registrador aún posee aproximadamente el espacio faltante, usaría su señal de reapertura admitida o un reinicio ordenado controlado. Evitaría matar el proceso o truncar /proc hasta que el propietario del servicio confirme el radio de impacto. Después de que se cierre el descriptor, comprobaría que df recupere el rango esperado y que la aplicación escriba en el nuevo registro con nombre.

Si eso no explica la brecha, inspeccionaría la salida de findmnt en busca de un directorio cuyos archivos subyacentes estén ocultos por otro montaje, revisaría los errores de permisos de du y luego usaría herramientas específicas del sistema de archivos para instantáneas, asignación copy-on-write, cuotas y metadatos. Dado que este volumen es ext4, inspeccionaría los bloques reservados. Pueden explicar por qué el servicio tiene cero bytes disponibles a pesar de que el total menos el usado es de 4 GiB, pero no pueden explicar la brecha de espacio usado de 78 GiB.

Terminaría repitiendo las mediciones originales, probando la ruta de escritura que falló, verificando el estado del servicio y la integridad de los datos, y registrando exactamente qué asignación se liberó. El trabajo de prevención consiste en corregir la rotación de registros o el ciclo de vida de los montajes, alertar tanto sobre bloques como sobre inodos y monitorear el crecimiento de archivos desvinculados pero abiertos antes de que el sistema de archivos alcance la reserva de emergencia”.

Errores comunes

• Eliminar el archivo visible más grande de inmediato → puede ser información requerida y puede no explicar una asignación invisible → alinea el alcance de la medición e identifica al propietario antes de modificar datos.
• Comparar df /var con du / → los sistemas de archivos anidados y diferentes raíces invalidan la resta → mapea la ruta que falla y usa du -x en el mismo sistema de archivos.
• Ignorar los errores de permisos de du → los archivos con nombre inalcanzables hacen que el total sea artificialmente bajo → ejecuta con suficientes privilegios y revisa cada diagnóstico.
• Ejecutar comandos en diferentes espacios de nombres de montaje → la misma ruta puede resolverse en diferentes sistemas de archivos → recolecta ambas mediciones en el espacio de nombres del proceso afectado.
• Llamar a la brecha de 78 GiB “bloques reservados” → la reserva de ext4 afecta la disponibilidad sin privilegios, mientras que la brecha compara los bloques usados con la asignación alcanzable → calcula cada diferencia por separado.
• Usar rm en un archivo que ya está eliminado pero abierto → su nombre final ya no existe y el descriptor activo mantiene el inodo asignado → haz que el proceso propietario cierre o reabra el descriptor de forma segura.
• Enviar kill -9 como primera solución → la terminación abrupta puede perder trabajo y omitir la limpieza → prefiere la vía de reapertura, recarga, reinicio ordenado o conmutación por error admitida.
• Truncar /proc/PID/fd/FD por costumbre → los desplazamientos retenidos y las suposiciones de formato de archivo pueden crear nueva corrupción → reserva el truncamiento para una emergencia aprobada con semántica verificada.
• Desmontar un montaje secundario ocupado para revelar archivos ocultos → los servicios dependientes pueden fallar de inmediato → inspecciona la topología y usa una vista alternativa aprobada o una ventana de mantenimiento.
• Tratar el uso de inodos como parte de la brecha de bytes → el agotamiento de inodos es un mecanismo independiente de ENOSPC → verifica df -i y diagnostica los conteos altos de archivos por separado.
• Aplicar comandos ext4 a todos los sistemas de archivos → la semántica de instantáneas y asignación difiere entre XFS, Btrfs, ZFS y capas overlay → identifica FSTYPE y usa sus herramientas compatibles.
• Detenerse después de que baje df → el escritor aún puede estar en mal estado o registrando en el destino incorrecto → verifica las escrituras de la aplicación, los archivos con nombre, la integridad de los datos y las señales de recurrencia.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Qué pasa si lsof no está disponible o no ve el proceso?

Inspecciona /proc/PID/fd en los mismos espacios de nombres de PID y montaje que el proceso de escritura, buscando enlaces simbólicos que terminen en (deleted), luego verifica el dispositivo, el inodo, el conteo de enlaces y la propiedad del proceso. El lsof del host puede no ver un proceso en contenedor si los permisos, los espacios de nombres de PID o la política de seguridad lo ocultan. No hagas del truncamiento de /proc el siguiente paso automático; la decisión de recuperación sigue siendo específica del servicio.

Pregunta de seguimiento 2: ¿Qué pasa si du es más grande que df?

Primero verifica si du cruzó a sistemas de archivos anidados; du -x elimina esa fuente. Luego revisa la semántica de los argumentos de enlaces duros, las opciones de tamaño aparente, la eliminación concurrente y la contabilidad de copy-on-write o compresión. du estima la jerarquía de directorios seleccionada, mientras que df reporta un sistema de archivos, por lo que la dirección de la discrepancia cambia qué error de alcance es plausible.

Pregunta de seguimiento 3: ¿Qué cambia en Btrfs o ZFS?

Los tamaños visibles de los archivos son insuficientes porque las instantáneas y el uso compartido copy-on-write pueden retener bloques después de que se elimina una ruta. Utiliza las vistas de espacio, subvolumen o dataset, instantáneas y cuotas propias del sistema de archivos; distingue la asignación referenciada de la exclusiva; y elimina instantáneas solo bajo una política de retención explícita. El razonamiento de bloques reservados de ext4 y tune2fs no son transferibles.

Pregunta de seguimiento 4: ¿Podemos establecer el porcentaje reservado de ext4 en cero para recuperar inmediatamente?

Solo después de una revisión de capacidad y confiabilidad. La reserva permite que los procesos privilegiados continúen y puede reducir la fragmentación. Puede restaurar la disponibilidad sin privilegios, pero no elimina los bloques usados ni explica la asignación de archivos eliminados pero abiertos. Recupera o amplía primero la capacidad conocida, luego ajusta la reserva de acuerdo con la función del volumen y la política operativa.

Pregunta de seguimiento 5: ¿Cómo reproducirías de forma segura el comportamiento de archivos eliminados pero abiertos?

Usa un sistema de archivos desechable o un host de prueba: abre un archivo de prueba grande con un proceso, desvincula su ruta mientras el descriptor permanece abierto, compara df y du, obsérvalo con lsof +L1, luego cierra el descriptor y confirma que los bloques regresan. No fabriques el experimento en un volumen de producción ni reutilices el descriptor de un servicio real.

Pregunta de seguimiento 6: ¿Qué debería medir la alerta a largo plazo?

Genera alertas sobre el tiempo hasta el agotamiento y el margen mínimo tanto para bloques como para inodos, segmentado por sistema de archivos y espacio de nombres. Agrega una métrica (gauge) o inventario periódico para archivos regulares eliminados pero abiertos, fallas de rotación de registros, crecimiento de instantáneas y cambios en la topología de montaje. La alerta debe enlazar a un runbook que comience con la alineación del alcance y requiera la aprobación del propietario antes de una recuperación destructiva.