Por Canuto  

EROFS deshabilitó temporalmente una optimización de LZ4 en Linux 7.3 después de que AWS identificara casos raros de corrupción de datos.
***

  • EROFS retirará temporalmente la descompresión rodante de LZ4 antes de Linux 7.3-rc3.
  • El problema estaría relacionado con copias de memoria hacia atrás no controladas en la implementación de LZ4 del kernel.
  • La medida aumenta el consumo de memoria, aunque un grupo de buffers reservado puede reducir parte del impacto.

EROFS prioriza la integridad de los datos

El sistema de archivos de solo lectura EROFS deshabilitó temporalmente su mecanismo de descompresión rodante de LZ4 debido a una posibilidad de corrupción de datos. La decisión llegó a mitad del ciclo de desarrollo, antes del lanzamiento previsto de Linux 7.3-rc3, y busca privilegiar la exactitud de la información almacenada por encima del ahorro de memoria que ofrecía la optimización.

EROFS se utiliza en sistemas embebidos, contenedores y otros entornos donde un sistema de archivos de solo lectura puede aportar eficiencia y estabilidad operativa. Por esa razón, el equipo de desarrollo consideró que no era prudente mantener activa una función capaz de producir resultados incorrectos, aunque el problema aparezca únicamente con conjuntos de datos LZ4 raros y específicos.

La alerta surgió cuando personal de AWS descubrió que algunos de sus sistemas podían obtener datos corruptos al procesar determinados archivos comprimidos con LZ4. El análisis posterior del responsable de EROFS apuntó a que ciertas copias de memoria hacia atrás, que la implementación actual de LZ4 puede realizar sin control suficiente, rompen una premisa necesaria para que la descompresión rodante funcione correctamente.

El cambio no implica que EROFS haya abandonado definitivamente la técnica ni que todos los datos comprimidos con LZ4 estén expuestos al mismo riesgo. La medida es preventiva y temporal, mientras los desarrolladores determinan si el código oficial de LZ4 debe modificarse o si EROFS tendrá que mantener una implementación propia para recuperar la optimización con garantías.

Por qué la descompresión rodante era importante

La descompresión rodante se incorporó a EROFS para reducir la cantidad de memoria temporal necesaria durante la lectura de datos comprimidos. En determinadas operaciones, el usuario solo necesita acceder a una porción pequeña de una extensión comprimida, conocida como pcluster, por ejemplo cuando realiza lecturas aleatorias pequeñas dentro de un archivo.

También existen casos en los que los folios ya actualizados, normalmente de orden 0, no pueden reutilizarse para repetir la descompresión. El algoritmo llena los folios que ya fueron actualizados, de modo que EROFS necesita reservar espacio adicional si no puede utilizar una ventana temporal que avance junto con el proceso de descompresión.

La optimización se apoya en la naturaleza de LZ4 como algoritmo basado en LZ77, cuyo funcionamiento solo requiere referencias a los 64 KiB más recientes de datos descomprimidos. En teoría, esa ventana limitada permite procesar una extensión completa con un conjunto acotado de páginas temporales, en lugar de conservar en memoria todos los datos necesarios para la operación.

El ahorro puede ser relevante en escenarios concretos. El parche de EROFS señala que datos de 601.960 bytes pueden comprimirse en una extensión LZ4 de 256k, lo que significa que desactivar la descompresión rodante puede exigir hasta 146 páginas adicionales por solicitud en el peor de los casos.

El conflicto con la implementación de LZ4

El problema aparece porque EROFS no controla por completo el código de LZ4 incorporado en el kernel Linux. Según la explicación asociada al cambio, la operación memmove() utilizada para copiar literales puede realizar copias largas hacia atrás en procesadores x86 según la comparación de direcciones, incluso cuando los rangos de origen y destino no se superponen.

Ese comportamiento resulta decisivo porque la descompresión rodante depende de que las copias respeten determinadas expectativas sobre el orden en que se escriben los datos. Cuando una copia hacia atrás altera ese supuesto, la ventana temporal deja de representar de forma segura los datos descomprimidos y la optimización puede producir información incorrecta.

La explicación del proyecto aclara que el problema no corresponde necesariamente a una descompresión en línea, ya que los rangos involucrados pueden no superponerse. El riesgo está en que una operación de copia aparentemente válida, ejecutada en una dirección inesperada, interfiere con la lógica que EROFS utiliza para ahorrar memoria durante la descompresión.

Por ahora, el equipo optó por una respuesta conservadora: desactivar la función y garantizar primero la corrección de los datos en entornos reales de producción. La posibilidad de reactivarla permanece abierta si el código oficial de LZ4 asegura que las copias hacia rangos no superpuestos siempre avanzan en la dirección esperada, o si EROFS adopta su propia implementación del algoritmo.

El costo operativo y los próximos pasos

El efecto más visible de la decisión será una mayor huella de memoria durante la ejecución de EROFS. Los sistemas que dependían del ahorro proporcionado por la ventana rodante podrían necesitar más páginas temporales para atender determinadas solicitudes, especialmente al leer extensiones comprimidas grandes o realizar accesos parciales.

Sin embargo, el impacto no será idéntico en todos los casos ni necesariamente alcanzará el peor escenario descrito por el parche. Un commit reciente, identificado como 0f6273ab4637 y titulado erofs: add a reserved buffer pool for lz4 decompression, incorpora un grupo de buffers reservado para la descompresión de LZ4, una medida que puede mitigar el aumento de memoria cuando está habilitada.

Los desarrolladores reconocen que ese grupo de buffers no resuelve por completo la tensión entre consumo de memoria y seguridad de los datos. Aun así, ofrece una herramienta para amortiguar el impacto mientras se revisa la arquitectura de la descompresión y se define una solución que no dependa de supuestos incumplidos por el comportamiento del código de LZ4.

Phoronix informó que la desactivación ya quedó incorporada para el ciclo de Linux 7.3, cuya siguiente referencia de desarrollo era Linux 7.3-rc3. El episodio deja una conclusión relevante para administradores y desarrolladores: una optimización de memoria puede perder prioridad de inmediato cuando existe la posibilidad, aunque sea excepcional, de alterar la integridad de los datos.

EROFS continuará necesitando una revisión técnica antes de recuperar la descompresión rodante de LZ4. Hasta que el proyecto pueda garantizar el comportamiento de las copias de memoria o controlar directamente la implementación utilizada, el sistema de archivos mantendrá una estrategia más costosa en memoria, pero más segura para los datos almacenados.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados