El equipo de desarrollo de EXT4 ha declarado obsoleto el modo de montaje «data=journal», la opción que fuerza el registro de los datos en el journal además de los metadatos. Tras esta deprecación, los desarrolladores han anunciado la intención de eliminar por completo ese modo en 2028.
Qué es el modo data=journal y por qué importa
En EXT4 existen varios modos de manejo del journal (registro), que determinan cómo se garantizan la integridad de metadatos y datos:
- data=ordered (comportamiento por defecto en muchas distribuciones): solo los metadatos se escriben en el journal; los datos se escriben en disco antes de actualizar los metadatos, lo que evita datos parciales tras un fallo en la mayoría de los casos.
- data=writeback: menos garantía de integridad de datos, mayor rendimiento en algunas cargas.
- data=journal: tanto datos como metadatos se registran en el journal antes de sincronizarlos al almacenamiento, lo que proporciona la máxima integridad frente a interrupciones, pero con coste de rendimiento y mayor uso de I/O y espacio de journal.
El modo data=journal ha sido usado en escenarios donde la integridad a toda prueba es prioritaria, por ejemplo en ciertos sistemas embebidos, appliances o cuando el almacenamiento es especialmente propenso a fallos. Sin embargo, también penaliza significativamente el rendimiento en comparación con los modos menos estrictos.
Por qué se ha deprecado
La decisión de descontinuar data=journal responde a varias razones técnicas y de mantenimiento explicadas por los desarrolladores:
- Complejidad de mantenimiento: mantener rutas de código y pruebas para un modo con uso minoritario añade carga al desarrollo del núcleo y del subsistema de ficheros.
- Impacto en rendimiento y uso de recursos: data=journal genera mayor I/O y más escritura en el journal, lo que lo hace poco adecuado para plataformas modernas y para medios con limitaciones de escritura como NAND/flash.
- Alternativas maduras: otras estrategias y modos ofrecen un equilibrio aceptable entre integridad y rendimiento para la mayoría de aplicaciones, reduciendo la necesidad de este modo extremo.
Quiénes se ven afectados y qué deben hacer
La deprecación afecta a quienes tengan sistemas montados explícitamente con data=journal (por ejemplo en /etc/fstab o en parámetros de montaje). Recomendaciones prácticas:
- Auditar sistemas: los administradores deben buscar entradas que usen data=journal en fstab, scripts de arranque y perfiles de contenedores.
- Evaluar alternativas: para la mayoría de los casos, data=ordered suele ser un sustituto razonable que mantiene integridad de metadatos sin el coste de registrar todos los datos. Si se requiere mayor seguridad en escritura, considerar estrategias de aplicación o almacenamiento (por ejemplo, capas de integridad a nivel de aplicación, sistemas de archivos en usuariospace especializados o dispositivos con protección de energía).
- Probar antes de migrar: cambiar el modo de montaje debe probarse en entornos de ensayo para verificar comportamiento y rendimiento. Hacer copias de seguridad antes de modificar fstab o scripts.
- Planificar la retirada: dado que la eliminación final está planeada para 2028, conviene programar la migración con tiempo para evitar interrupciones en sistemas críticos.
Impacto para sitios web y hosting
Para la mayoría de servidores web y entornos de hosting, data=journal no es lo habitual por su impacto en el rendimiento. No obstante, servidores que por política interna o por diseños especiales empleen ese modo deben adaptarse. El cambio no afecta la compatibilidad de datos en sí, sino la configuración de montaje; no es necesario reformatear volúmenes, sólo ajustar la opción de montaje y validar.
Conclusión
La deprecación de data=journal en EXT4 es un aviso anticipado para inconsistencia de soporte y para impulsar migraciones a modos más sostenibles. Administradores y responsables de infraestructuras deben identificar usos actuales de ese modo, evaluar alternativas y planificar la transición antes de su eliminación prevista en 2028.
Lee también:
- MariaDB publica una biblioteca pública para detectar cambios de rendimiento en su Test Automation Framework
- Portainer lanza la versión LTS 2.45.2 con correcciones de seguridad y mejoras para Kubernetes
Fuente: Phoronix
