Linux: Corrupción de datos en Ext4 en 6.1.64-1
Un error grave en el sistema de archivos ext4 del Linux 6.1.64 provoca corrupción silenciosa de datos cuando los archivos se escriben con E/S directa, lo que llevó a Debian a retrasar su versión 12.3 y bloquear el paquete del kernel afectado. Los comentaristas examinan cómo un par de parches aguas arriba desincronizados se coló en kernels estables de largo plazo, planteando preocupaciones más amplias sobre el proceso de retroportación del kernel estable de Linux, los límites de las distribuciones “estables” y la rapidez con que estos problemas pueden detectarse y mitigarse mediante la infraestructura de la distribución y las prácticas de los usuarios.
Alcance y naturaleza del error
- La corrupción de datos en ext4 ocurre en ciertos kernels estables de Linux 6.1 cuando se usa E/S directa (O_DIRECT), debido a un cambio de ext4 retroportado que dependía de otro cambio de E/S directa que no fue retroportado.
- Si ambos commits están presentes (por ejemplo, en kernels más nuevos), el comportamiento es correcto; si solo está presente el commit de ext4 (por ejemplo, 6.1.64/65), las escrituras pueden ir a un desplazamiento incorrecto.
- La corrupción se describe como “no catastrófica”: los metadatos del sistema de archivos permanecen intactos, pero el contenido de archivos individuales puede corromperse silenciosamente, algo especialmente grave para imágenes de VM y bases de datos que usan O_DIRECT.
Responsabilidad aguas arriba frente a Debian
- Varios comentarios subrayan que se trata de un error del kernel estable aguas arriba, no de un problema de empaquetado solo de Debian; Debian sigue las versiones estables de kernel.org.
- En el hilo surge cierta confusión; otros aclaran, usando changelogs del kernel y enlaces a listas de correo, que la 6.1.64 aguas arriba está afectada y que la 6.1.66 contiene la corrección.
- Se dice que algunos kernels de Ubuntu no se ven afectados porque no incluyen 6.1 por defecto.
Crítica al proceso del kernel estable
- Fuerte crítica al modelo de retroportación pesada: miles de commits incorporados a ramas LTS antiguas, con riesgo no trivial de dependencias.
- Preocupa que los kernels “estables” cambien demasiado rápido y ahora sean menos estables que el resto de Debian; algunos prefieren ejecutar solo el kernel mainline más reciente.
- Incidente relacionado: otro parche dependiente faltante en 6.1.66 que rompió Wi‑Fi y que luego se corrigió en 6.1.67, reforzando las dudas sobre el proceso.
Gestión y actualizaciones en Debian
- Algunos usuarios se quejan de que unattended-upgrades instaló el kernel defectuoso incluso después de conocerse el error grave.
- Se dan explicaciones: las herramientas del archivo de Debian no están diseñadas para revocar paquetes de forma instantánea; los nuevos kernels deben compilarse para muchas arquitecturas y luego propagarse por espejos que solo se sincronizan unas pocas veces al día.
- Se comentan soluciones temporales: fijar 6.1.64-1 con un archivo de preferencias de apt, arrancar un kernel anterior y desactivar correctamente
unattended-upgradesdeteniendo/deshabilitando la unidad.timero reconfigurando el paquete.
Sistemas de archivos y recuperación
- Algunos ven esto como una refutación de las afirmaciones de que ext4 es intrínsecamente más seguro que ZFS o btrfs; otros enfatizan que todos los sistemas de archivos tienen errores.
- Se elogia ext4 por su fsck maduro y su disposición simple de metadatos, y se afirma que permite recuperar casi cualquier daño; los escépticos cuestionan cuánto datos reales del usuario salva eso en la práctica.
Gravedad y “pérdida de datos no grave”
- Debate sobre los términos de Debian: “grave” frente a “pérdida de datos no grave”, y si la corrupción que puede corregirse con fsck (o copias de seguridad) cuenta realmente como “recuperable” en la práctica.
- Se subraya que la corrupción silenciosa es especialmente peligrosa porque las copias de seguridad pueden ingerir datos dañados sin detectarlo.