¿Cuál es la diferencia entre los diferentes sistemas de “compresión”?

Siempre he usado TAR y ZIP para la compresión, pero recientemente he oído hablar del algoritmo de compresión *.Z . Esto me trajo una pregunta:

Con todos estos sistemas de compresión, ¿cuál es el mejor para uso general y compresión?

Al realizar algunas pruebas, descubrí que el tar , como descubrí, NO se comprime realmente (a menos que se especifique explícitamente). Es decir, ¿para qué es bueno en comparación con otros métodos de compresión?

Ya sé que ZIP es el sistema de compresión más utilizado, pero ¿debería utilizarlo en lugar de *.Z , *.7z , .tar o .tar. ?

Resumen de la publicación:

  1. ¿Debo usar *.tar , *.Z , *.7z , .tar o .tar. para obtener la mejor compresión?
  2. Si plain *.tar no se comprime, ¿por qué lo usamos?

EDITAR: No todos los algoritmos permiten almacenar permisos de Linux (de lo que aprendí). ¿Qué hago, y hay algún tipo de hack (o script) que podría usar para almacenar permisos?

tar significa archivo de cinta. Todo lo que hace es empaquetar archivos y sus metadatos (permisos, propiedad, etc.) en un flujo de bytes que se pueden almacenar en una unidad de cinta (o un archivo) y restaurar posteriormente. La compresión es un asunto completamente separado que solía tener que canalizar la salida a través de una utilidad externa para comprimir si se desea. GNU tar fue lo suficientemente bueno como para agregar interruptores para indicar que filtre automáticamente la salida a través de la utilidad apropiada como acceso directo.

Zip y 7z combinan el archivo y la compresión en su propio formato de contenedor, y están destinados a empaquetar archivos en un sistema DOS / Windows, por lo que no almacenan los permisos y la propiedad de Unix. Por lo tanto, si desea almacenar permisos para realizar copias de seguridad adecuadas, debe atenerse a tar. Si planea intercambiar archivos con usuarios de Windows, entonces zip o 7z es bueno. El uso de los algoritmos de compresión zip y 7zip se puede usar con tar, al eliminar gzip y lzma respectivamente.

lzma (aka. * .xz) tiene una de las mejores relaciones de compresión, y es bastante rápida en la descompresión, lo que la convierte en la mejor opción en estos días. Sin embargo, sí requiere una tonelada de RAM y CPU para comprimir. El venerable gzip es un poco más rápido en compresión, por lo que puede usarse si no quieres dedicar tanto tiempo de CPU. También tiene una variante aún más rápida llamada lzop. bzip2 sigue siendo bastante popular, ya que reemplazó en gran medida a gzip durante un tiempo antes de que se produjera 7zip / lzma, ya que tiene mejores relaciones de compresión, pero en estos días está perdiendo el favor, ya que 7z / lzma es más rápido en la descompresión y tiene mejores relaciones de compresión. La utilidad de compress , que normalmente nombra archivos * .Z, es antigua y hace mucho que se olvida.

Una de las otras diferencias importantes entre zip y tar es que zip comprime los datos en trozos pequeños, mientras que cuando comprimes un archivo tar, comprimes todo de una vez. Este último proporciona mejores relaciones de compresión, pero para extraer un solo archivo al final del archivo, debes descomprimir todo para poder acceder a él. Por lo tanto, el formato zip es mejor para extraer uno o dos archivos de un archivo grande. 7z y dar permiten elegir comprimir todo (lo que se denomina modo “sólido”) o trozos pequeños para una extracción por partes fácil.

Los detalles de los algoritmos están fuera de tema aquí 1 ya que no son de ninguna manera específicos de Linux, y mucho menos de Ubuntu. Sin embargo, encontrarás información interesante aquí .

Ahora en tar , como dijiste, tar no es y nunca ha sido un progtwig de compresión. En cambio, es un archivador ; su propósito principal es hacer un archivo grande de muchos pequeños. Históricamente esto fue para facilitar el almacenamiento en unidades de cinta, de ahí el nombre: Tape ARchive.

Hoy en día, la razón principal para usar tar es disminuir el número de archivos en su sistema. Cada archivo en un sistema de archivos Unix ocupa un inodo , cuantos más archivos tenga, menos inodos disponibles y cuando se quede sin inodos, ya no podrá crear nuevos archivos. En pocas palabras, la misma cantidad de datos almacenados que miles de archivos ocuparán más de su disco duro que esos mismos archivos en un solo archivo tar.

Para ilustrar, dado que esto se ha cuestionado en los comentarios, en mi 68G / partition, tengo el siguiente número de inodos totales y utilizados (tenga en cuenta que el recuento de inodos depende del tipo de sistema de archivos y el tamaño de la partición):

 Inode count: 393216 Free inodes: 171421 

Si ahora procedo a intentar crear más archivos de los que tengo inodes:

 $ touch {1..171422} touch: cannot touch '171388': No space left on device touch: cannot touch '171389': No space left on device touch: cannot touch '171390': No space left on device touch: cannot touch '171391': No space left on device touch: cannot touch '171392': No space left on device touch: cannot touch '171393': No space left on device touch: cannot touch '171394': No space left on device touch: cannot touch '171395': No space left on device touch: cannot touch '171396': No space left on device touch: cannot touch '171397': No space left on device 

¿Sin espacio? Pero tengo un montón de espacio:

 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 5,8G 4,3G 1,2G 79% / 

Como puede ver arriba, crear unos cientos de miles de archivos vacíos agota rápidamente mis inodos y ya no puedo crear nuevos. Si tuviera que guardarlos, podría empezar a crear archivos de nuevo.

Tener menos archivos también acelera en gran medida la E / S del sistema de archivos, especialmente en los sistemas de archivos montados en NFS. Siempre ataco mis antiguos directorios de trabajo cuando finaliza un proyecto, ya que cuantos menos archivos tenga, más rápido funcionarán los progtwigs como find .

Hay una gran respuesta sobre el Superusuario que entra en muchos más detalles, pero además de lo anterior, las otras razones básicas por las que el tar sigue siendo popular hoy en día son:

  1. Eficiencia: usar tar para canalizar a través de un progtwig de compresión como gzip es más eficiente, ya que evita la creación de archivos intermedios.

  2. tar viene con todo tipo de campanas y silbidos, características que han sido diseñadas a lo largo de su larga historia que lo hacen particularmente útil para las copias de seguridad * nix (piense en los permisos, la propiedad de archivos, la capacidad de canalizar los datos directamente a STDOUT y a través de un enlace SSH .. .)

  3. Inercia. Estamos acostumbrados al tar . Es seguro asumir que estará disponible en cualquier * nix que pueda usar, lo que lo hace muy portátil y útil para los archivos de código fuente.


1 Esto es absolutamente cierto y no tiene nada que ver con el hecho de que no sé lo suficiente para explicarles 🙂

Hay dos tareas distintas pero relacionadas. El empaquetado de un árbol de archivos (incluidos los nombres de archivos, la estructura de directorios, los permisos del sistema de archivos, la propiedad y cualquier otro metadato) en un flujo de bytes se denomina archivo . La eliminación de la redundancia en un flujo de bytes para producir un flujo de bytes más pequeño se denomina compresión .

En Unix, las dos operaciones están separadas, con herramientas distintas para cada una. En la mayoría de las otras plataformas (actuales e históricas), las herramientas combinadas realizan tanto el archivado como la compresión.

(gzip y otros progtwigs que imitan la interfaz de gzip a menudo tienen la opción de almacenar el nombre del archivo original en la salida comprimida, pero esto, junto con un CRC u otra verificación para detectar daños, es el único metadato que pueden almacenar).

Hay ventajas en separar la compresión del archivo. El archivo es específico de la plataforma (los metadatos del sistema de archivos que necesitan preservación varían ampliamente), pero la implementación es sencilla, en gran parte vinculada a E / S, y cambia poco con el tiempo. La compresión es independiente de la plataforma, pero las implementaciones están vinculadas a la CPU y los algoritmos están mejorando constantemente para aprovechar el aumento de los recursos que el hardware moderno puede aportar al problema.

El archivador de Unix más popular es tar , aunque existen otros como cpio y ar . (Los paquetes de Debian son archivos ar , mientras que cpio se usa a menudo para los ramsys iniciales). Tar se combina o combina con herramientas de compress como compress (.Z), gzip (.gz), bzip2 (.bz2) y xz (. xz), desde la más antigua a la más joven, y no por coincidencia desde la peor a la mejor compresión.

Hacer un archivo tar y comprimirlo son pasos distintos: el compresor no sabe nada sobre el formato del archivo tar . Esto significa que extraer un solo archivo de un archivo comprimido de tar requiere descomprimir todos los archivos anteriores. Esto a menudo se llama un archivo “sólido”.

Del mismo modo, dado que tar es un formato de “transmisión por secuencias”, que se requiere para que sea útil en una canalización, no hay un índice global en un archivo tar, y enumerar los contenidos de un archivo tar es tan costoso como extraerlo.

Por el contrario, Zip y RAR y 7-zip (los archivadores más populares en las plataformas modernas de Windows) por lo general comprimen cada archivo por separado y, si es que lo hacen, comprimen los metadatos a la ligera. Esto permite una lista barata de los archivos en un archivo y la extracción de archivos individuales, pero significa que la redundancia entre múltiples archivos en el mismo archivo no puede ser explotada para boost la compresión. Si bien en general, comprimir un archivo ya comprimido no reduce aún más el tamaño del archivo, es posible que en ocasiones vea un archivo zip dentro de un archivo zip: el primer archivo comprimido convirtió muchos archivos pequeños en un archivo grande (probablemente con la compresión desactivada), mientras que el segundo comprimir luego comprimido como una sola entidad.

Existe una polinización cruzada entre las diferentes plataformas y filosofías: gzip es esencialmente un compresor zip sin su archivador, y xz es esencialmente un compresor 7-zip sin su archiver.

Hay otros compresores especializados. Las variantes de PPM y su sucesor ZPAQ están optimizadas para una compresión máxima sin importar el consumo de recursos. Pueden masticar fácilmente la CPU y la RAM que se le ofrecen, y la descompresión es tan exigente como la compresión (para el contraste, las herramientas de compresión más utilizadas son asimétricas : descomprimir es más barato que comprimir).

En el otro extremo del espectro, lzo , snappy y LZ4 son compresores “ligeros” diseñados para la máxima velocidad y el mínimo consumo de recursos, al costo de la compresión. Se utilizan ampliamente en sistemas de archivos y otros almacenes de objetos, pero no tanto como herramientas independientes.


Entonces, ¿cuál debería elegir?

Archivando

Ya que está en Ubuntu, no hay ninguna razón real para usar otra cosa que no sea tar para archivar, a menos que esté tratando de hacer que los archivos sean fácilmente legibles en otros lugares.

zip es difícil de superar por su ubicuidad, pero no está centrado en Unix y no mantendrá los permisos de su sistema de archivos y la información de propiedad, y su compresión integrada está anticuada. 7-zip y RAR (y ZPAQ) tienen una compresión más moderna, pero son igualmente inadecuados para archivar sistemas de archivos Unix (aunque no hay nada que le impida usarlos solo como compresores); RAR también es propietario.

Compresión:

Para una compresión máxima, puede echar un vistazo a un punto de referencia, como el enorme en http://mattmahoney.net/dc/text.html . Esto debería darle una mejor idea de las compensaciones involucradas.

Aunque probablemente no quieras la compresión máxima. Es demasiado caro.

xz es la herramienta de compresión de propósito general más popular en los sistemas modernos de Unix. Creo que 7-zip también puede leer archivos xz, ya que están estrechamente relacionados.

Finalmente: si está archivando datos para otra cosa que no sea el almacenamiento a corto plazo, debe elegir algo de código abierto y preferiblemente generalizado, para minimizar los dolores de cabeza más adelante.

lzo, gz, b2, lzma (.lzma2 =.xz) son compresores de “flujo”: comprimen un flujo de byes y no se preocupan por los archivos, directorios y metadatos, como los permisos. Debe utilizar un archivador como tar para agrupar todos esos datos en un flujo de bytes (un archivo tar) y comprimirlo con un compresor. Si le importan los datos de un solo archivo, también podría enviar ese archivo solo a uno de estos compresores.

Tar, cpio and pax son archivadores: toman un montón de archivos y directorios y codifican los datos y metadatos en un solo archivo. El alquitrán es el más popular y el más compatible, aunque los méritos técnicos entre los tres son lo suficientemente mínimos como para que hubiera guerras religiosas al respecto en los albores del tiempo.

7z y zip son compresores AND arcihvers: luego almacene todos los datos y metadatos y comprímalos. Sin embargo, AFAICT, ninguno de ellos guarda los permisos de Unix.

Zip usa el mismo algoritmo que gzip llamado DEFLATE. 7z usa el algoritmo lzma

para leer un solo archivo desde un archivo tar.gz o similar, deberá descomprimir todo el flujo de gz hasta que se exponga la cantidad suficiente del archivo tar para poder extraerlo. Zip te permite comprimir y sacar cada archivo individualmente. 7z puede tener cualquier comportamiento.

Relaciones y velocidades de compresión: gzip y lzo tienen velocidades de compresión y descompresión muy rápidas pero relaciones de compresión bajas. Tampoco se necesita mucha memoria para comprimir. gzip es un poco más lento y ofrece una relación de compresión un poco mejor que lzo.

Es tan rápido que puede ser más rápido leer un archivo comprimido en gz o lzo del disco y descomprimirlo sobre la marcha en lugar de leer el archivo sin comprimir directamente desde el disco.

LZMA (xz) ofrece una excelente compresión en los datos generales, pero demora mucho en comprimir y descomprimir, además de llevar una cantidad significativa de memoria a comprimir.

bz2 solía ser el algoritmo de compresión de alta elección, pero cayó en desgracia ya que es más lento que lzma y tarda más en comprimir y descomprimir. Sin embargo, para ciertos tipos de datos (secuencias de ADN, archivos con ejecuciones muy grandes del mismo byte, etc.) bzip2 puede vencer a todo lo demás. Como ejemplo, una vez tuve que comprimir un archivo de 4GB de 1’s y b2 redujo i a unos 10’s de kb, mientras que lzma tomó unos 10’s de MB si recuerdo correctamente.

Para archivos especialmente grandes, puede usar rzip . Primero mira los datos redundantes dentro de bloques grandes de 900 MB, los codifica y luego los entrega a bzip2 (no realmente, pero se usan los mismos algoritmos).

¿Efecto? Mucho más rápido que xz , lzma o bzip2 , y en mi experiencia su relación de compresión rivaliza con la de lzma . Es un cerdo RAM, sin embargo.

http://en.wikipedia.org/wiki/Rzip