compression - ¿Por qué*.tar.gz sigue siendo mucho más común que*.tar.xz?
zip decompression (9)
"Mínimo común denominador". El espacio adicional ahorrado rara vez vale la pena por la pérdida de interoperabilidad. La mayoría de los sistemas Linux integrados tienen gzip, pero no xz. Muchos sistemas antiguos también. Gnu Tar, que es el estándar de la industria, admite los indicadores -z para procesar a través de gzip, y -j para procesar a través de bzip2 , pero algunos sistemas antiguos no admiten el indicador -J para xz , lo que significa que requiere una operación de 2 pasos (y mucho de espacio de disco extra para .tar sin comprimir a menos que use la sintaxis de |tar xf - - que mucha gente no conoce.) Además, descomprimir el sistema de archivos completo de unos 10 MB de tar.gz en ARM incrustado toma unos 2 minutos. no es realmente un problema No hay idea de xz pero bzip2 toma alrededor de 10-15 minutos. Definitivamente no vale la pena el ancho de banda guardado.
Cuando veo algunos paquetes fuente o binarios comprimidos con GZip, me pregunto si todavía hay razones para favorecer a gz sobre xz (excluyendo el viaje en el tiempo a 2000), los ahorros del algoritmo de compresión LZMA son sustanciales y las descompresiones no son magnitudes peores gzip
Del autor de la utilidad de compresión Lzip:
Xz tiene un formato complejo, parcialmente especializado en la compresión de ejecutables y diseñado para ser extendido por formatos propietarios. De los cuatro compresores probados aquí, xz es el único ajeno al concepto de Unix de "hacer una cosa y hacerlo bien". Es lo menos apropiado para compartir datos, y no lo es en absoluto para el archivado a largo plazo.
En general, cuanto más complejo es el formato, menos probable es que pueda decodificarse en el futuro. Pero el formato xz, al igual que su infame predecesor lzma-alone, está especialmente mal diseñado. Xz copia casi todos los defectos de gzip y luego agrega algunos más, como los frágiles enteros de longitud variable. Solo un bit-flip en el bit 7 de cualquier byte de un entero de longitud variable y todo el flujo xz se derrumba como un castillo de naipes. No es aconsejable usar xz para otra cosa que no sea la compresión de ejecutables de corta duración.
No me interpretes mal Estoy muy agradecido a Igor Pavlov por inventar / descubrir LZMA, pero xz es el tercer intento de sus seguidores por aprovechar la popularidad de 7zip y reemplazar gzip y bzip2 con formatos inapropiados o mal diseñados. En particular, es vergonzoso que el soporte para lzma-alone se haya implementado tanto en GNU como en Linux.
Hice mi propio punto de referencia en la imagen vmdk de instalación de Linux de 1.1GB:
rar =260MB comp= 85s decomp= 5s
7z(p7z)=269MB comp= 98s decomp=15s
tar.xz =288MB comp=400s decomp=30s
tar.bz2=382MB comp= 91s decomp=70s
tar.gz =421MB comp=181s decomp= 5s
todos los niveles de compresión en max, CPU Intel I7 3740QM, memoria 32GB 1600, fuente y destino en disco RAM
Generalmente uso rar o 7z para archivar archivos normales como documentos.
y para archivar archivos del sistema, uso .tar.gz o .tar.xz por file-roller o tar con las opciones -z o -J junto con --preserve para comprimir de forma nativa con tar y preservar los permisos (también alternativamente .tar.7z o .tar.rar puede ser usado)
actualización: como tar solo conserva los permisos normales y no las ACL de todos modos, también se puede usar la versión .7z más la copia de seguridad y los permisos de restauración y las ACL de forma manual a través de getfacl y sefacl, que parece ser la mejor opción tanto para el archivo de archivos como para la copia de seguridad de los archivos del sistema porque estará completa conserva los permisos y las ACL, tiene suma de comprobación, prueba de integridad y capacidad de cifrado, el único inconveniente es que p7zip no está disponible en todas partes
Honestamente, acabo de conocer el formato .xz de un material de capacitación. Así que acabo de usar su git repo para hacer una prueba. El git es git: //git.free-electrons.com/training-materials.git, y también compilé las tres diapositivas de entrenamiento. El tamaño total del directorio es 91M, con una mezcla de texto y datos binarios.
Aquí está mi resultado rápido. Tal vez la gente aún prefiere tar.gz simplemente porque es mucho más rápido de comprimir? Personalmente, incluso uso alquitrán plano cuando no se obtienen muchos beneficios en la compresión.
[02:49:32]wujj@WuJJ-PC-Linux /tmp $ time tar czf test.tgz training-materials/
real 0m3.371s
user 0m3.208s
sys 0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux /tmp $ time tar cJf test.txz training-materials/
real 0m34.557s
user 0m33.930s
sys 0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux /tmp $ time tar cf test.tar training-materials/
real 0m0.117s
user 0m0.020s
sys 0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux /tmp $ ll test*
-rw-rw-r-- 1 wujj wujj 91944960 2012-07-09 02:51 test.tar
-rw-rw-r-- 1 wujj wujj 69042586 2012-07-09 02:49 test.tgz
-rw-rw-r-- 1 wujj wujj 60609224 2012-07-09 02:50 test.txz
[02:56:03]wujj@WuJJ-PC-Linux /tmp $ time tar xzf test.tgz
real 0m0.719s
user 0m0.536s
sys 0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux /tmp $ time tar xf test.tar
real 0m0.189s
user 0m0.004s
sys 0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux /tmp $ time tar xJf test.txz
real 0m3.116s
user 0m2.612s
sys 0m0.184s
La respuesta final es la accesibilidad, con una respuesta secundaria de propósito. Razones por las que XZ no es necesariamente tan adecuado como Gzip:
Es mucho más probable que los sistemas integrados y heredados carezcan de suficiente memoria disponible para descomprimir archivos LZMA / LZMA2 como XZ. Como ejemplo, si XZ puede eliminar 400 KiB (frente a Gzip) de un paquete destinado a un enrutador OpenWrt, ¿de qué sirve el pequeño ahorro de espacio si el enrutador tiene 16 MiB de RAM? Una situación similar aparece con sistemas informáticos muy antiguos. Uno podría burlarse de la idea de descargar y compilar la última versión de Bash en una antigua SparcStation LX con 32 MB de RAM, pero sucede.
Dichos sistemas suelen tener procesadores lentos, y los aumentos de tiempo de descompresión pueden ser muy altos. Tres segundos adicionales para descomprimir en su Core i5 pueden ser muy largos en un núcleo ARM de 200 MHz o en un microSPARC de 50 MHz. La compresión Gzip es extremadamente rápida en tales procesadores en comparación con todos los mejores métodos de compresión, como XZ o incluso Bzip2.
Gzip es prácticamente universalmente compatible con todos los sistemas similares a UNIX (y casi todos los sistemas que no son similares a UNIX) creados en las últimas dos décadas. La disponibilidad de XZ es mucho más limitada. La compresión es inútil sin la capacidad de descomprimirla.
Una compresión más alta lleva mucho tiempo. Si el tiempo de compresión es más importante que la relación de compresión, Gzip supera a XZ. Honestamente, lzop es mucho más rápido que Gzip y todavía se comprime bien, por lo que las aplicaciones que necesitan la compresión más rápida posible y no requieren la ubicuidad de Gzip deberían ver eso en su lugar. Ruturo aleatoriamente las carpetas a través de una conexión LAN de confianza con comandos como "tar -c * | lzop -1 | socat -u - tcp-connect: 192.168.0.101: 4444" y Gzip podría usarse de manera similar en un enlace mucho más lento ( es decir, haciendo lo mismo que acabo de describir a través de un túnel SSH a través de Internet).
Ahora, por otro lado, hay situaciones en las que la compresión XZ es muy superior:
Envío de datos a través de enlaces lentos. El código fuente del kernel de Linux 3.7 es 34 MiB más pequeño en formato XZ que en formato Gzip. Si tiene una conexión súper rápida, elegir XZ podría significar ahorrar un minuto de tiempo de descarga; en una conexión DSL barata o una conexión celular 3G, podría reducir una hora o más del tiempo de descarga.
Reducción de los archivos de copia de seguridad. Al comprimir el código fuente de httpd-2.4.2 de Apache con "gzip-9" en lugar de "xz -9e", se obtiene un archivo XZ que tiene un 62.7% del tamaño del archivo Gzip. Si existe la misma compresibilidad en un conjunto de datos que actualmente almacena como 100 archivos GiB de archivos .tar.gz, la conversión a archivos .tar.xz eliminaría 37,3 GiB del conjunto de copia de seguridad. Copiar todo este conjunto de datos de copia de seguridad en un disco duro USB 2.0 (con un máximo de alrededor de 30 transferencias de MiB / seg), ya que los datos Gzipped tardarían 55 minutos, pero la compresión XZ haría que la copia de seguridad tomara 20 minutos menos. Suponiendo que trabajará con estas copias de seguridad en un sistema de escritorio moderno con mucha potencia de CPU y la velocidad de compresión de una sola vez no es un problema grave, el uso de la compresión XZ generalmente tiene más sentido. ¿Por qué barajar datos adicionales si no es necesario?
Distribuir grandes cantidades de datos que podrían ser altamente compresibles. Como se mencionó anteriormente, el código fuente de Linux 3.7 es 67 MiB para .tar.xz y 101 MiB para .tar.gz; El código fuente sin comprimir es de unos 542 MiB y es casi completamente de texto. El código fuente (y el texto en general) suele ser altamente compresible debido a la cantidad de redundancia en los contenidos, pero los compresores como Gzip que operan con un diccionario mucho más pequeño no aprovechan la redundancia que va más allá de su tamaño de diccionario.
En última instancia, todo se reduce a una compensación de cuatro vías: tamaño comprimido, velocidad de compresión / descompresión, velocidad de copia / transmisión (lectura de los datos del disco / red) y disponibilidad del compresor / descompresor. La selección depende en gran medida de la pregunta "¿qué planea hacer con estos datos?"
También puedes ver este post relacionado del cual aprendí algunas de las cosas que repito aquí.
Por la misma razón, la gente en Windows (r) usa archivos zip en lugar de 7zip, y algunos todavía usan rar en lugar de otros formatos ... O mp3 se usa en música, en lugar de aac +, y así sucesivamente.
Cada formato tiene sus beneficios y las personas utilizan para atenerse a una solución que aprendieron cuando comenzaron a usar una computadora. Agregue esto a la compatibilidad con versiones anteriores y al ancho de banda rápido + GB o TB de espacio en los discos duros, y los beneficios de una mayor compresión no serán tan relevantes.
Sí, el pensamiento que tuve es que la pregunta original podría ser replanteada en estos días como "¿por qué es tar.gz más común que tar.lz?" (Ya que lz parece comprimirse ligeramente mejor que xz , se said que xz es una mala elección para archivar , aunque ofrece algunas características agradables como el acceso aleatorio). Supongo que la respuesta es "impulso", la gente está acostumbrada a usarlo, hay un buen soporte de bibliotecas, etc., etc. La introducción de lz puede significar que xz crecerá menos rápido ahora, también, FWIW ...
Sin embargo, dicho esto, lz parece descomprimir más lento que xz, y hay cosas nuevas en el horizonte como Brotli, por lo que no está claro qué sucederá en términos de popularidad ... pero parece que hay algunos archivos .lz en el mundo salvaje FWIW ...
También un punto importante para gzip es que es interoperable con rsync / zsync . Esto podría ser un gran beneficio en relación con el ancho de banda en los casos. LZMA / bzip2 / xz no admite rsync y probablemente no lo admita en el corto plazo.
Una de las características de LZMA es que utiliza una ventana grande y silenciosa. Para que sea amigable con rsync / zsync , probablemente necesitaríamos reducir esta ventana, lo que degradaría su rendimiento de compresión.
gz es compatible en todas partes y bueno para la portabilidad.
xz es más nuevo y ahora está ampliamente o bien soportado. Es más complejo que gzip con más opciones de compresión.
Esta no es la única razón por la que las personas no siempre usan xz. Xz puede tardar mucho tiempo en comprimir, no una cantidad de tiempo trivial, por lo que incluso si puede producir resultados superiores, es posible que no siempre se elija. Otra debilidad es que puede usar una gran cantidad de memoria, especialmente para la compresión. Cuanto más quiera comprimir un artículo por más tiempo, esto es exponencial con rendimientos decrecientes.
Sin embargo, en el nivel de compresión 1 para los elementos binarios grandes en mi experiencia, xz a menudo puede producir resultados mucho más pequeños en menos tiempo que zlib en el nivel 9. Esto a veces puede ser una diferencia muy significativa, al mismo tiempo que zlib, xz puede hacer un archivo eso es la mitad del tamaño del archivo de zlib.
bzip2 está en una situación similar, sin embargo, xz tiene ventajas muy superiores y una ventana sólida donde se desempeña significativamente mejor en todos los aspectos.