J'ai un tas de fichiers gzip que je dois convertir en bzip2 de temps en temps. Actuellement, j'utilise un script shell qui se contente de "gunzip" chaque fichier, puis "bzip2". Bien que cela fonctionne, cela prend beaucoup de temps.
Est-il possible de rendre ce processus plus efficace? Je suis prêt à plonger et à regarder les codes sources de gunzip et bzip2 si nécessaire, mais je veux juste être sûr du résultat. Y a-t-il un espoir d'améliorer l'efficacité du processus?
Réponses:
Cette question a été posée il y a longtemps lorsque pbzip2 n'était pas disponible ou n'était pas capable de compresser à partir de stdin, mais vous pouvez désormais paralléliser les étapes de décompression et de compression à l'aide de parallel et pbzip2 (au lieu de bzip2 ):
ls *.gz | parallel "gunzip -c {} | pbzip2 -c > {.}.bz2"
ce qui est nettement plus rapide que d'utiliser bzip2 .
Plutôt que gunzip dans une étape et bzip2 dans une autre, je me demande s'il serait peut-être plus efficace d'utiliser des tuyaux. Quelque chose commegunzip --to-stdout foo.gz | bzip2 > foo.bz2
Je pense qu'avec deux processeurs ou plus, ce serait certainement plus rapide. Mais peut-être même avec un seul cœur. Je reconnais honteusement de ne pas avoir essayé cela, cependant.
bzip2et gzipne fonctionnent pas en interne en parallèle, à l'aide d' un tuyau , vous pouvez faire travailler en parallèle, car une conduite commence implicitement deux processus qui vont fonctionner en parallèle. Ainsi, au moins la décompression et la compression s'exécuteront en parallèle.
bzip2l'utilisation du CPU éclipse gunzipcelle, donc en pratique le parallélisme que vous obtenez ici est minime. Ne pas avoir à faire d'E / S sur disque est quand même bien!
GNU parallèle ( http://www.gnu.org/software/parallel ) peut être une option si vous avez plusieurs cœurs (ou même plusieurs machines):
ls *.gz | parallel "gunzip -c {} | bzip2 > {.}.bz2"
Lisez le tutoriel / page de manuel pour les détails et les options.
Ce que vous faites actuellement est votre meilleur pari. Il n'y a pas d'outil de conversion disponible, et tenter de bzip2 un fichier déjà compressé n'est pas vraiment une option, car il a souvent des effets indésirables. Étant donné que l'algorithme est différent, la conversion impliquerait de récupérer les données d'origine malgré tout. À moins bien sûr que le gzipping ne soit une étape du processus bzip2, ce qui n'est malheureusement pas le cas.
gziputilise Leimpel-Ziv 77, tandis que bzip2Burrows-Wheeler. Différents algorithmes, je le crains.
Parfois, je dois faire la même chose avec les fichiers journaux. Je commence par les plus petits fichiers * .gz d'abord ( ls -rS), gunzip, puis et bzip2 individuellement. Je ne sais pas s'il est possible de diriger la sortie gunzip directement vers l'entrée bzip2. La commande bzip2 est tellement plus lente en compression que gunzip en décompression qu'elle peut consommer de la mémoire et échanger de l'espace sur l'hôte.
Les améliorations ou suggestions sont les bienvenues. Voici ma seule doublure:
for i in $(ls -rS *.gz | sed 's/\.gz//'); do gunzip ${i}.gz; bzip2 -9 ${i}; done
Si vous en avez plusieurs, consultez l'article de LJ avec un joli script shell.
http://linuxgazette.net/123/bechtel.html
7zip obtient une meilleure compression et est multi-thread.
Je viens de le faire il y a quelques minutes:
find . -name "*.gz" | perl -pi -e 's/\.gz$//g;' | xargs -n1 ./rezip
Où rezipserait défini comme:
#!/bin/bash
gunzip -v $1.gz && bzip2 -9v $1
En option, vous pouvez également le rendre multi-thread en utilisant une -Poption avec xargs, mais soyez prudent avec celle-ci. (Commencez bas!)
pbzip2mention. Si le lien ne se charge pas pour quelqu'un d'autre, voici la page du projet et la page de manuel .