¿Por qué los formatos de archivo tar están cambiando a la compresión xz para reemplazar bzip2 y qué pasa con gzip?

Para distribuir archivos a través de Internet, las siguientes cosas son generalmente una prioridad:

1. Relación de compresión (es decir, qué tan pequeños hacen los datos el compresor);
2. Tiempo de descompresión (requisitos de CPU) ;
3. Requisitos de memoria de descompresión; y
4. Compatibilidad (qué tan extendido está el programa de descompresión)

Memoria de compresión & Los requisitos de CPU no son muy importante, porque puedes usar una máquina grande y rápida para eso, y solo tienes que hacerlo una vez.

Comparado con bzip2, xz tiene una mejor relación de compresión y menor (mejor) tiempo de descompresión. Sin embargo, en la configuración de compresión que se usa normalmente, requiere más memoria para descomprimir ^[1] y está algo menos extendido. Gzip usa menos memoria que cualquiera de los dos.

Por lo tanto, se publican archivos en formato gzip y xz, lo que le permite elegir:

• Necesidad de descomprimir en una máquina con memoria muy limitada (< 32 MB): gzip. Dado, no es muy probable cuando se habla de fuentes del kernel.
• Necesita descomprimir las herramientas mínimas disponibles: gzip
• Quiere ahorrar tiempo de descarga y / o ancho de banda: xz

Realmente no existe una combinación realista de factores que le hagan elegir bzip2. Por lo tanto, está siendo eliminado.

Miré las comparaciones de compresión en una publicación de blog . No intenté replicar los resultados, y sospecho que algo ha cambiado (principalmente, espero que xz haya mejorado, ya que es el más nuevo).

(Existen algunos escenarios específicos en los que una buena implementación de bzip2 puede ser preferible a xz: bzip2 puede comprimir un archivo con muchos ceros y secuencias de ADN del genoma mejor que xz. Las versiones más nuevas de xz ahora tienen un modo de bloque (opcional) que permite datos recuperación después del punto de corrupción y compresión paralela y [en teoría] descompresión. Anteriormente, solo bzip2 ofrecía estos. ^[2] Sin embargo, ninguno de estos es relevante para la distribución del kernel)

1: en tamaño de archivo, xz -3 es aproximadamente bzip -9. Entonces xz usa menos memoria para descomprimir. Pero xz -9 (como, por ejemplo, se usa para los archivos tar del kernel de Linux) usa mucho más que bzip -9. (E incluso xz -0 necesita más de gzip -9).

2: F21 Cambio en todo el sistema: lbzip2 como implementación predeterminada de bzip2

Comentarios

• Cualquier comentario sobre el tema de tolerancia a fallas o es algo que ‘ s siempre implementa completamente fuera de los algoritmos de compresión?
• @illumin É No se puede ‘ proporcionar resistencia sin sacrificar la relación de compresión. Es ‘ un problema ortogonal, y aunque existen herramientas como Parchive, para distribuir el TCP del núcleo ‘, el manejo de errores funciona igual que bueno.
• @illumin É La tolerancia a fallas (asumiendo que te refieres a algo similar a par2) no es ‘ t normalmente preocupación por la distribución de archivos a través de Internet. Se supone que las descargas son lo suficientemente confiables (y puede volver a descargarlas si están dañadas). A menudo se utilizan hashes y firmas criptográficas, que detectan tanto la corrupción como la manipulación. Hay compresores que ofrecen una mayor tolerancia a fallos, aunque a costa de la relación de compresión. Nadie parece encontrar la compensación que valga la pena para las descargas HTTP o FTP.
• xz usa MENOS memoria para descomprimir.
• @Mike ¿Ha cambiado desde que escribí esto? En particular, la nota al pie de página uno explica el uso de la memoria.

En primer lugar, esta pregunta no está directamente relacionada a tar. Tar simplemente crea un archivo sin comprimir, la compresión se aplica más tarde.

Se sabe que Gzip es relativamente rápido en comparación con LZMA2 y bzip2. Si la velocidad importa, gzip (especialmente la implementación multiproceso pigz ) suele ser un buen compromiso entre la velocidad de compresión y la relación de compresión. Aunque hay alternativas si la velocidad es un problema (por ejemplo, LZ4).

Sin embargo, si se desea una relación de compresión alta, LZMA2 supera a bzip2 en casi todos los aspectos. La velocidad de compresión suele ser más lenta, pero se descomprime mucho más rápido y proporciona una relación de compresión mucho mejor a costa de un mayor uso de memoria.

No hay muchas razones para usar bzip2 más, excepto por compatibilidad con versiones anteriores. Además, LZMA2 se diseñó teniendo en cuenta el subproceso múltiple y muchas implementaciones de forma predeterminada utilizan CPU multinúcleo (desafortunadamente, xz en Linux aún no hace esto). Esto tiene sentido ya que las velocidades de reloj «no aumentarán más, pero la cantidad de núcleos sí lo hará.

Hay implementaciones de bzip2 multiproceso (por ejemplo, pbzip ), pero a menudo no se instalan de forma predeterminada. También tenga en cuenta que los bzip2 multiproceso solo vale la pena mientras comprime mientras que la descompresión usa un solo hilo si el archivo se comprime usando un solo hilo bzip2, en contraste con LZMA2. Paralelo bzip2 Las variantes solo pueden aprovechar las CPU multinúcleo si el archivo se comprimió con una versión bzip2 paralela, que a menudo no es el caso.

Comentarios

• Bueno, algunos tars asimilan una opción z.
• » speed » es una respuesta confusa, debes referirte a la velocidad de compresión o descompresión. Ni pixz, pbzi p2 o pigz están instalados por defecto (o son usados por tar sin el indicador -I), pero pixz y pbzip2 aceleran la compresión y descompresión y pigz es solo para compresión.
• @Tobu xz será multiproceso de forma predeterminada, por lo que no se requerirá ninguna instalación pixz en el futuro. En algunas plataformas, xz ya es compatible con subprocesos. Mientras que bzip2 es poco probable que alguna vez sea multiproceso ya que el formato no fue ‘ t diseñado teniendo en cuenta el multiproceso. Además, pbzip2 solo acelera la descompresión si el archivo se ha comprimido con pbzip2, lo cual no suele ser el caso.
• @Marco Creo que lbzip2 permite la descompresión paralela de archivos incluso si fueron comprimidos con una implementación no paralela (por ejemplo, stock bzip2). Esa ‘ es la razón por la que utilizo lbzip2 en lugar de pbzip2. (Es ‘ posible que esto haya evolucionado desde su comentario.)
• This makes sense since the clock speeds won't increase any more – ¿qué? que ‘ no es del todo cierto. la publicación se realizó en 2014, cuando Intel lanzó el i3-4370 a 3.8GHz. en 2017, Intel lanzó i7-8700K a 4,7 GHz. en 2018 lanzaron el i9-9900K a 5GHz, y probablemente haya ‘ s probablemente cpus en 2015 & 2016 que ‘ también falta en esta lista

LZMA2 es un sistema de compresión de bloques mientras que gzip no lo es. Esto significa que LZMA2 se presta para múltiples subprocesos. Además, si se daña un archivo, generalmente puede recuperar datos de bloques posteriores con LZMA2, pero no puede hacerlo con gzip. En la práctica, pierde todo el archivo con gzip después del bloque dañado. Con un archivo LZMA2, solo pierde los archivos afectados por los bloques dañados. Esto puede ser importante en archivos más grandes con varios archivos.

Comentarios

• ¡Esta es una distinción muy útil e importante, de hecho!
• ¿Puede respaldar estas afirmaciones con fuentes? Todavía no he visto una herramienta de recuperación XZ, y mi fuente conocida afirma lo contrario: nongnu.org/lzip/xz_inadequate.html

Respuesta corta : xz es más eficiente en términos de relación de compresión. Por lo tanto, ahorra espacio en disco y optimiza la transferencia a través de la red.
Puede ver este Quick Benchmark para descubrir la diferencia mediante pruebas prácticas.

Comentarios

• El enlace está roto.
• Nuevo enlace: catchchallenger.first -world.info/wiki/…