¿Pueden los archivos tarring mejorar la compresión?

¿Puede agrupar un montón de archivos juntos mejorar la compresión con las herramientas estándar, por ejemplo, gzip, bzip2, xz?

Durante mucho tiempo pensé que este era el caso, pero nunca lo probé. Si tenemos 2 copias del mismo archivo de 20Mb de bytes aleatorios alquilados juntos, un programa de compresión inteligente que se dé cuenta de esto podría comprimir todo el tarball hasta casi 20Mb.

Acabo de probar este experimento usando gzip, bzip2 y xz para comprimir 1) un archivo de bytes aleatorios, 2) un tarball de dos copias de ese archivo y 3) un gato de dos copias de ese archivo. En todos los casos, la compresión no redujo el tamaño del archivo. Esto se espera para el caso 1, pero para los casos 2 y 3, el resultado óptimo es que un archivo de 40Mb puede reducirse a casi 20Mb. Esa es una visión difícil de ver para un programa de compresión, especialmente porque la redundancia es distante, por lo que no esperaría un resultado perfecto, pero todavía pensé que habría algo de compresión.

Prueba:

dd if=/dev/urandom of=random1.txt bs=1M count=20
cp random1.txt random2.txt
cat random1.txt random2.txt > random_cat.txt
tar -cf randoms.tar random1.txt random2.txt
gzip -k random* &
bzip2 -k random* &
xz -k random* &
wait
du -sh random*

Resultado:

20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 1.40937 s, 14.9 MB/s
[1]   Done                    gzip -k random*
[2]-  Done                    bzip2 -k random*
[3]+  Done                    xz -k random*
20M random1.txt
21M random1.txt.bz2
21M random1.txt.gz
21M random1.txt.xz
20M random2.txt
21M random2.txt.bz2
21M random2.txt.gz
21M random2.txt.xz
40M random_cat.txt
41M random_cat.txt.bz2
41M random_cat.txt.gz
41M random_cat.txt.xz
41M randoms.tar
41M randoms.tar.bz2
41M randoms.tar.gz
41M randoms.tar.xz

¿Es esto generalmente lo que debo esperar?

¿Hay alguna manera de mejorar la compresión aquí?

Te enfrentas al "tamaño de bloque" del compresor. La mayoría de los programas de compresión dividen la entrada en bloques y comprimen cada bloque. Parece que el tamaño del bloque bzip solo sube a 900K, por lo que no verá ningún patrón que tarde más de 900K bytes en repetirse.

http://www.bzip.org/1.0.3/html/memory-management.html

gzip parece usar bloques de 32K.

¡Con xz estás de suerte! Desde la página del manual:

   Preset   DictSize   CompCPU   CompMem   DecMem
     -0     256 KiB       0        3 MiB    1 MiB
     -1       1 MiB       1        9 MiB    2 MiB
     -2       2 MiB       2       17 MiB    3 MiB
     -3       4 MiB       3       32 MiB    5 MiB
     -4       4 MiB       4       48 MiB    5 MiB
     -5       8 MiB       5       94 MiB    9 MiB
     -6       8 MiB       6       94 MiB    9 MiB
     -7      16 MiB       6      186 MiB   17 MiB
     -8      32 MiB       6      370 MiB   33 MiB
     -9      64 MiB       6      674 MiB   65 MiB

entonces "xz -8" encontrará patrones de hasta 32MB y "xz -9" patrones de hasta 64MB. Pero tenga cuidado con la cantidad de ram que se requiere para realizar la compresión (y descomprimir) ...

El contenido de archivo aleatorio que eligió no es un buen ejemplo: los archivos tar comprimidos serán más grandes que los originales. Verá lo mismo con los archivos en formatos ya comprimidos (muchos formatos de imagen / audio / video, por ejemplo).

Pero la tarificación de varios archivos con contenido compresible normalmente produciría un tamaño de archivo tar total más pequeño que cuando se tardan por separado, especialmente cuando el contenido es similar (por ejemplo, archivos de registro del mismo programa). La razón es que algunos de los datos de compensación de compresión por archivo (como las matrices de patrones para algunos algoritmos de compresión) podrían ser compartidos por todos los archivos en el mismo archivo tar.

Como ya se indicó:

1. El uso de archivos aleatorios no es bueno ya que ya contienen la máxima "entropía de información", por lo tanto, no se comprimirán;
2. Necesita empaquetar muchos archivos para una comparación justa.

Un mejor caso de prueba podría ser este:

cd /var/tmp
tar -zcf test1.tar /usr
tar -cf test2.tar /usr
gzip test2.tar
ls -h

(Nota: ¡Esperando que no haya monturas debajo /usr!)

Puede usar tar -jcfpara la compresión xz en su lugar.

Ahora, si test2.tar.gzes más pequeño que test1.tar.gz, entonces la prueba es exitosa (es decir, los archivos de tarring entonces la compresión es mejor que la compresión de tarring). Supongo que lo será, para muchos (es decir, miles) de archivos. La desventaja es que potencialmente llevará más tiempo ejecutarlo, además de requerir mucho más espacio en disco, ya que primero tiene que construir todo el archivo tar y luego comprimirlo. Es por eso que el primer método se usa a menudo en su lugar, ya que comprime cada archivo sobre la marcha, a pesar de que puede no dar un tarball tan pequeño.

Por ejemplo, en nuestra copia de seguridad fuera del sitio, generalmente hacemos copias de seguridad de 4,000,000 de archivos por un total de aproximadamente 2TB. Por lo tanto, el primer método es mucho más rápido y no requiere 2 TB adicionales de disco.