Les fichiers de goudron peuvent-ils améliorer la compression?

Le goudronnage d'un ensemble de fichiers peut-il améliorer la compression avec les outils standard, par exemple gzip, bzip2, xz?

J'ai longtemps pensé que c'était le cas, mais je ne l'ai jamais testé. Si nous avons 2 copies du même fichier de 20 Mo d'octets aléatoires goudronnées ensemble, un programme de compression intelligent qui s'en rend compte pourrait compresser l'intégralité de l'archive tar jusqu'à presque 20 Mo.

Je viens d'essayer cette expérience en utilisant gzip, bzip2 et xz pour compresser 1) un fichier d'octets aléatoires, 2) une archive tar de deux copies de ce fichier et 3) un chat de deux copies de ce fichier. Dans tous les cas, la compression n'a pas réduit la taille du fichier. Cela est attendu pour le cas 1, mais pour les cas 2 et 3, le résultat optimal est qu'un fichier de 40 Mo peut être réduit à près de 20 Mo. C'est un aperçu difficile à voir pour un programme de compression, surtout parce que la redondance est éloignée, donc je ne m'attendais pas à un résultat parfait, mais j'avais toujours pensé qu'il y aurait une compression.

Tester:

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*

Résultat:

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

Est-ce généralement ce à quoi je dois m'attendre?

Y a-t-il un moyen d'améliorer la compression ici?

Vous êtes face à la "taille de bloc" du compresseur. La plupart des programmes de compression divisent l'entrée en blocs et compressent chaque bloc. Il semble que la taille du bloc bzip ne monte que jusqu'à 900K, donc il ne verra aucun modèle qui prend plus de 900K octets à répéter.

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

gzip semble utiliser des blocs de 32 Ko.

Avec xz, vous avez de la chance! Depuis la page de manuel:

   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

donc "xz -8" trouvera jusqu'à 32 Mo de motifs et "xz -9" jusqu'à 64 Mo de motifs. Mais attention à la quantité de RAM nécessaire pour effectuer la compression (et pour décompresser) ...

Le contenu de fichier aléatoire que vous avez choisi n'est pas un bon exemple - les fichiers tar compressés seront plus gros que les originaux. Vous verrez la même chose avec des fichiers dans des formats déjà compressés (de nombreux formats image / audio / vidéo, par exemple).

Mais tarer ensemble plusieurs fichiers avec un contenu compressible produirait généralement une taille totale de fichier tar inférieure à celle de les tarer séparément, en particulier lorsque le contenu est similaire (par exemple les fichiers journaux du même programme). La raison en est que certaines des données de décalage de compression par fichier (comme les tableaux de modèles pour certains algorithmes de compression) peuvent être partagées par tous les fichiers du même fichier tar.

Comme déjà indiqué:

1. L'utilisation de fichiers aléatoires n'est pas bonne car ils contiennent déjà une "entropie d'informations" maximale, donc ne seront pas compressés;
2. Vous devez emballer beaucoup de fichiers pour une comparaison équitable.

Un meilleur cas de test pourrait être le suivant:

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

(Remarque: en espérant qu'il n'y ait pas de montures sous /usr!)

Vous pouvez utiliser tar -jcfpour la compression xz à la place.

Maintenant, si test2.tar.gzest plus petit que test1.tar.gz, le test est réussi (c.-à-d. Taraudage des fichiers, puis compression est meilleur que compression puis taraudage). Je suppose que ce sera le cas pour de nombreux (c'est-à-dire des milliers) de fichiers. L'inconvénient est qu'il prendra potentiellement plus de temps à exécuter, tout en nécessitant beaucoup plus d'espace disque, car il doit d'abord construire l'intégralité du fichier tar, puis le compresser. C'est pourquoi la 1ère méthode est souvent utilisée à la place, car elle compresse chaque fichier à la volée, même si elle ne donne pas un tarball aussi petit.

Par exemple, dans notre sauvegarde hors site, nous sauvegardons généralement 4 000 000 de fichiers totalisant environ 2 To. La première méthode est donc beaucoup plus rapide et ne nécessite pas 2 To supplémentaires de disque.