I file tarring possono migliorare la compressione?

Riunire insieme un sacco di file può migliorare la compressione con gli strumenti standard, ad esempio gzip, bzip2, xz?

Ho pensato a lungo che fosse così, ma non l'ho mai provato. Se abbiamo 2 copie dello stesso file da 20 Mb di byte casuali tarati insieme, un programma di compressione intelligente che si rende conto che questo potrebbe comprimere l'intero tarball fino a quasi 20 Mb.

Ho appena provato questo esperimento usando gzip, bzip2 e xz per comprimere 1) un file di byte casuali, 2) un tarball di due copie di quel file e 3) un gatto di due copie di quel file. In tutti i casi la compressione non ha ridotto le dimensioni del file. Ciò è previsto per il caso 1, ma per i casi 2 e 3 il risultato ottimale è che un file da 40 Mb può essere ridotto a quasi 20 Mb. È una visione difficile da vedere per un programma di compressione, soprattutto perché la ridondanza è distante, quindi non mi aspetto un risultato perfetto ma ho comunque pensato che ci sarebbe stata una certa compressione.

Test:

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*

Risultato:

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

È generalmente quello che dovrei aspettarmi?

C'è un modo per migliorare la compressione qui?

Sei contro la "dimensione del blocco" del compressore. La maggior parte dei programmi di compressione suddivide l'input in blocchi e comprime ogni blocco. Sembra che la dimensione del blocco bzip salga solo a 900K, quindi non vedrà alcun pattern che richiede più di 900K byte per ripetere.

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

gzip sembra usare blocchi da 32K.

Con xz sei fortunato però! Dalla pagina man:

   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

così "xz -8" troverà fino a 32 MB di schemi e "xz -9" fino a 64 MB di schemi. Ma attenzione a quanto RAM richiede per eseguire la compressione (e decomprimere) ...

Il contenuto casuale del file che hai scelto non è un buon esempio: i tarfile compressi saranno più grandi degli originali. Vedrai lo stesso con i file in formati già compressi (molti formati di immagini / audio / video, ad esempio).

Ma il raggruppamento di più file con contenuto comprimibile in genere produrrebbe una dimensione totale del tarfile inferiore rispetto a quando li tarare separatamente, specialmente quando i contenuti sono simili (ad esempio file di registro dello stesso programma). Il motivo è che alcuni dei dati di offset della compressione per file (come array di pattern per alcuni algoritmi di compressione) potrebbero essere condivisi da tutti i file nello stesso tarfile.

Come già indicato:

1. L'uso di file casuali non è buono poiché contengono già la massima "entropia di informazioni", quindi non si comprimono;
2. È necessario comprimere molti file per un confronto equo.

Un caso di test migliore potrebbe essere questo:

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

(Nota: sperando che non ci siano supporti sotto /usr!)

È possibile utilizzare invece tar -jcfper la compressione xz.

Ora se test2.tar.gzè più piccolo di test1.tar.gz, allora il test ha esito positivo (vale a dire tarring dei file, quindi comprimere è meglio che comprimere quindi tarring). La mia ipotesi è che sarà, per molti (cioè migliaia) di file. Il rovescio della medaglia è che potrebbe richiedere più tempo per l'esecuzione, oltre a richiedere molto più spazio su disco, poiché deve prima creare l'intero file tar e quindi comprimerlo. Ecco perché viene spesso utilizzato il primo metodo, poiché comprime ogni file al volo, anche se potrebbe non essere un tarball così piccolo.

Ad esempio, nel nostro backup offsite di solito eseguiamo il backup di 4.000.000 di file per un totale di circa 2 TB. Quindi il primo metodo è molto più veloce e non richiede 2 TB aggiuntivi di disco.