El proyecto LZ4 publicó el 4 de noviembre de 2026 la versión 1.11.0 de su compresor y de la biblioteca liblz4, que incorpora compresión multihilo en la propia API de tramas (lz4frame), acelera la descompresión en x86-64 y aarch64 y corrige varios fallos de corrupción de datos en usos válidos. Según las notas de la versión, liblz4 mantiene la compatibilidad binaria con las anteriores y el equipo recomienda actualizar.
Las claves de LZ4 1.11.0 en 30 segundos
- La biblioteca comprime con varios hilos (opción experimental nbWorkers) y el resultado no cambia con el número de hilos.
- El proyecto cifra la mejora de descompresión en hasta un 19 %, y un 4 % sobre silesia.tar.
- Corrige corrupciones de datos y una escritura fuera de límites presente desde la 1.10.0; no se publica ningún CVE.
- En una prueba propia, LZ4 descomprime más rápido que gzip, xz o bzip2, aunque comprime menos.
LZ4 es un algoritmo de compresión sin pérdida de la familia LZ77 que prima la velocidad sobre la ratio. Lo mantiene Yann Collet, el mismo autor de Zstandard (zstd), y está integrado en el kernel Linux, en zram, en OpenZFS, en SquashFS y en multitud de bases de datos. La 1.11.0 sucede a la 1.10.0 como versión estable y no cambia el formato de los ficheros .lz4, así que lo comprimido con versiones anteriores se sigue leyendo sin problemas.
Qué trae LZ4 1.11.0: multihilo en la biblioteca y descompresión más rápida
El cambio de más calado está en la API. La 1.10.0 ya permitía comprimir con varios hilos desde la línea de comandos, pero ahora esa capacidad vive en liblz4 a través del campo LZ4F_preferences_t.nbWorkers, todavía marcado como experimental. El registro de cambios precisa que la salida es idéntica sea cual sea el número de hilos, algo útil para quien necesita compilaciones reproducibles o verificar sumas de comprobación. La herramienta lz4 se apoya ahora en esa función, suma la opción --memory=# para fijar un presupuesto de memoria al trabajar con -T# y añade --single-thread para forzar un único hilo.
En rendimiento, el proyecto habla de una descompresión hasta un 19 % más rápida en aarch64 y x86-64 (un 4 % con silesia.tar), de mejoras de hasta el 80 % al comprimir bloques pequeños reutilizando estados y del 35 % con diccionarios, y de niveles 11 y 12 entre un 8 % y un 27 % más rápidos. Las compilaciones para x86 evitan además la penalización de la errata JCC de Intel, con ganancias que el equipo sitúa en hasta un 12 % en compresión y un 31 % en descompresión en procesadores de la familia Skylake. Son cifras del propio proyecto.
Las correcciones pesan tanto como las novedades. La versión arregla una corrupción de datos en la decodificación con búfer circular (presente desde la 1.9.0) y en casos raros de compresión en streaming, una posible truncación al descomprimir tramas concatenadas con suma de bloque y una escritura fuera de límites en la descompresión multihilo tras más de 2^31 tramas, introducida en la 1.10.0. También endurece la validación de argumentos inválidos. Ni las notas ni el registro de cambios asignan identificadores CVE (Common Vulnerabilities and Exposures) a estos fallos.
Hay cambios de API que afectan a quien programa contra liblz4: LZ4_decompress_safe() devuelve ahora códigos distintos (-1 entrada mal formada, -2 destino pequeño, -3 falta el diccionario), llegan funciones experimentales de acceso aleatorio (LZ4F_resumeFrame(), LZ4F_seek(), LZ4F_tell()), se retiran de las cabeceras funciones obsoletas desde la 1.7 y la 1.8 (la biblioteca las sigue exportando) y LZ4F_compressOptions_t debe inicializarse a cero. La CLI aprende a leer los ficheros mozlz4 de Firefox, rechaza sobrescribir la entrada y conserva el original si falla --rm. En CMake se exporta el objetivo lz4::lz4.
Ubuntu 24.04 todavía empaqueta la 1.9.4, que no tiene -T. Para probar la nueva versión basta con compilarla desde la etiqueta, como se hizo para este artículo:
sudo apt install lz4 # paquete de la distribución (1.9.4 en Ubuntu 24.04)
git clone --branch v1.11.0 https://github.com/lz4/lz4.git
cd lz4 && make -j"$(nproc)" && sudo make install
lz4 --version
lz4 -9 datos.tar # nivel alto (HC), genera datos.tar.lz4
lz4 -T2 --memory=512M -f datos.tar datos.tar.lz4 # dos hilos con tope de memoria
lz4 -t datos.tar.lz4 # comprobar integridad
lz4 -d datos.tar.lz4 restaurado.tar # descomprimir
lz4 --list datos.tar.lz4 # información de tramas
tar -I lz4 -cf copia.tar.lz4 /ruta # tar con lz4
lz4 -b1 -e3 datos.tar # benchmark en memoria de los niveles 1 a 3Lenguaje del código: PHP (php)En Fedora, RHEL y derivadas el paquete también se llama lz4 y se instala con dnf install lz4, aunque la versión disponible dependerá de cada distribución.
Comparativa de LZ4 con zstd, gzip, xz, 7z, rar, bzip2, brotli y Snappy
Antes de comparar conviene separar dos cosas. Deflate, LZMA, LZ4 o zstd son algoritmos; zip, 7z y rar son formatos contenedor que archivan varios ficheros con su estructura de directorios y usan un algoritmo por debajo (zip suele emplear Deflate y 7z, LZMA2). gzip, xz, bzip2, zstd o lz4 comprimen un único flujo, por eso en Linux se combinan con tar. RAR es un formato propietario: unrar es gratuito, pero el compresor rar es software comercial.
La tabla recoge una prueba propia sobre un tar reproducible de 102.963.200 bytes con los directorios kernel, mm, fs y net del código fuente de Linux 6.8 (paquete linux-source-6.8.0 de Ubuntu). Se ejecutó en una máquina virtual KVM con 2 vCPU Intel Xeon a 2,10 GHz y Ubuntu 24.04, midiendo con la herramienta de línea de comandos el mejor de tres tiempos de reloj, con lectura desde la caché de página y salida a disco o a /dev/null. Todo va con un hilo salvo lo indicado. Snappy no tiene CLI estándar y se midió en memoria con su API en C. Son cifras orientativas de un entorno virtualizado y de un corpus de texto muy compresible, no comparables en términos absolutos con las de otras fuentes.
| Herramienta y nivel | Ratio | Compresión (MB/s) | Descompresión (MB/s) | Licencia | Uso típico |
|---|---|---|---|---|---|
| LZ4 1.11.0 -1 | 2,741 | 329 | 830 | BSD-2 (biblioteca), GPL-2.0+ (CLI) | zram, ZFS, logs, datos en tiempo real |
| LZ4 1.11.0 -1 -T2 (2 hilos) | 2,741 | 522 | 967 | BSD-2 / GPL-2.0+ | Volcados grandes en paralelo |
| LZ4 1.11.0 -9 (HC) | 3,788 | 32,5 | 949 | BSD-2 / GPL-2.0+ | Comprimir una vez, leer muchas |
| LZ4 1.11.0 -12 | 3,827 | 17,7 | 1.036 | BSD-2 / GPL-2.0+ | Imágenes de arranque, firmware |
| Snappy 1.1.10 (API, en memoria) | 2,645 | 444 | 753 | BSD-3 | Bases de datos, RPC |
| zstd 1.5.5 -1 | 3,929 | 262 | 958 | BSD o GPLv2 | Btrfs, streaming, backups rápidos |
| zstd 1.5.5 -3 | 4,403 | 176 | 780 | BSD o GPLv2 | Uso general, paquetes |
| zstd 1.5.5 -19 | 6,216 | 1,3 | 543 | BSD o GPLv2 | Distribución de paquetes |
| gzip 1.12 -6 (Deflate) | 4,417 | 30,2 | 185 | GPLv3 | Compatibilidad universal, web |
| pigz 2.8 -6 (2 hilos, Deflate) | 4,416 | 96,6 | 467 | zlib | gzip en paralelo |
| zip 3.0 -6 (contenedor, Deflate) | 4,417 | 29,5 | 160 | Info-ZIP (tipo BSD) | Intercambio con Windows y macOS |
| bzip2 1.0.8 -9 | 5,787 | 11,5 | 28,7 | Tipo BSD | Archivos heredados |
| xz 5.4.5 -6 (LZMA2) | 6,324 | 1,4 | 108 | Dominio público (0BSD desde 5.6) | Tarballs, paquetes |
| 7-Zip 23.01 -mx=5 (contenedor 7z, LZMA2) | 6,276 | 1,4 | 104 | LGPL con partes BSD | Archivado con máxima ratio |
| RAR 7.00 -m3 (contenedor) | 5,771 | 3,4 | 249 | Propietaria (unrar gratuito) | Archivos con registro de recuperación |
| brotli 1.1.0 -q 5 | 5,188 | 37,4 | 445 | MIT | Compresión HTTP |
La medición por CLI incluye arranque del proceso, lectura, escritura y sumas de comprobación, lo que penaliza a los más rápidos. En memoria, con su propio modo de benchmark, LZ4 1.11.0 marcó 453 MB/s al comprimir y 2.478 MB/s al descomprimir en el nivel 1, y 2.698 MB/s al descomprimir el nivel 9; zstd 1.5.5 -1 quedó en 322 y 1.175 MB/s. La paralelización también cuenta: con dos hilos, LZ4 produjo el mismo fichero byte a byte que con uno, como promete el registro de cambios.
Las referencias públicas apuntan en la misma dirección con otros números. El README de LZ4 1.11.0, con lzbench 2.4.1, GCC 13.3 y un Core i7-9700K sobre el corpus Silesia, da a LZ4 una ratio de 2,112 con 770 MB/s y 4.950 MB/s, frente a 2,896, 510 y 1.570 MB/s de zstd 1.5.7 -1. El README de zstd, en el mismo modelo de CPU pero con GCC 14.2, atribuye a LZ4 1.10.0 675 y 3.850 MB/s. lzbench 2.4, en un AMD EPYC 9555P, mide LZ4 1.10.0 a 550 y 3.832 MB/s, y xz 5.8.4 -9 a 2,75 MB/s comprimiendo. Las diferencias se deben a la CPU, el compilador, la versión y el corpus.
Cuándo elegir LZ4 y cuándo otro compresor
LZ4 encaja donde la descompresión está en el camino crítico. En zram, el dispositivo de bloques comprimido en RAM, lz4 es una de las opciones del kernel junto a zstd y lzo-rle. OpenZFS lo usa como algoritmo por defecto cuando se activa compression=on, y SquashFS e initramfs lo admiten para arrancar más deprisa a cambio de algo más de tamaño; el kernel puede comprimirse con LZ4 mediante CONFIG_KERNEL_LZ4. Btrfs, en cambio, solo ofrece zlib, LZO y zstd, como se contó en la llegada de la compresión zstd en tiempo real a Btrfs. En bases de datos, PostgreSQL acepta lz4 para TOAST y ClickHouse lo usa por defecto.
zstd es la opción equilibrada: en la prueba, el nivel 1 logró una ratio un 43 % mayor que LZ4 -1 (un fichero un 30 % más pequeño) con una descompresión similar por CLI, y escala hasta ratios cercanas a xz. Por eso Arch Linux y Fedora lo usan en sus paquetes y muchas herramientas de backup lo ofrecen por defecto. xz y 7z ganan en ratio, pero comprimen a poco más de 1 MB/s por hilo, así que tienen sentido en tarballs y distribución de software que se comprime una vez y se descarga muchas. gzip y zip siguen ahí por compatibilidad, y pigz es la forma sencilla de acelerar gzip con varios núcleos. bzip2 queda superado en casi todo, brotli sigue siendo una elección habitual para contenido web y RAR solo se justifica si se necesita su formato. Para archivado con 7-Zip, este medio ya repasó la comparativa de 7-Zip 25.00 con más de 64 hilos.
Preguntas frecuentes
¿Es compatible LZ4 1.11.0 con los ficheros de versiones anteriores?
Sí. El formato no cambia y el proyecto asegura que liblz4 sigue siendo compatible a nivel binario con versiones anteriores, aunque retira de las cabeceras algunas funciones obsoletas.
¿Corrige LZ4 1.11.0 alguna vulnerabilidad con CVE?
Las notas no citan ningún CVE. Sí corrigen corrupciones de datos en usos válidos y una escritura fuera de límites en la descompresión multihilo introducida en la 1.10.0.
¿Qué comprime más, LZ4 o zstd?
zstd comprime más a igualdad de nivel rápido. LZ4 destaca en velocidad de descompresión, sobre todo medida en memoria.
¿Cómo se usa LZ4 con varios hilos?
Con la opción -T seguida del número de hilos, por ejemplo lz4 -T4 fichero, y desde la 1.11.0 se puede limitar la memoria con –memory. El resultado es idéntico al de un solo hilo.
Fuentes:
