Ho un sacco di file gzip che devo convertire in bzip2 ogni tanto. Attualmente sto usando uno script di shell che semplicemente 'gunzip è ogni file e poi' bzip2 è tutto. Anche se funziona, ci vuole molto tempo per completarlo.
È possibile rendere questo processo più efficiente? Sono pronto a fare un tuffo e cercare i codici sorgente di gunzip e bzip2 se necessario, ma voglio solo essere sicuro del risultato. C'è qualche speranza di migliorare l'efficienza del processo?
Risposte:
Questa domanda è stata posta molto tempo fa quando pbzip2 non era disponibile o non era in grado di comprimere da stdin, ma ora è possibile parallelizzare sia i passaggi non compressi che quelli compressi utilizzando parallel e pbzip2 (anziché bzip2 ):
ls *.gz | parallel "gunzip -c {} | pbzip2 -c > {.}.bz2"
che è significativamente più veloce rispetto all'utilizzo di bzip2 .
Invece di gunzip in un passo e bzip2 in un altro, mi chiedo se sarebbe forse più efficiente usare le pipe. Qualcosa di simile agunzip --to-stdout foo.gz | bzip2 > foo.bz2
Sto pensando con due o più CPU, questo sarebbe sicuramente più veloce. Ma forse anche con un solo core. Ammetto vergognosamente di non averlo provato, però.
bzip2e gzipnon funzionano in parallelo internamente, usando una pipe puoi farle lavorare in parallelo, perché una pipe avvia implicitamente due processi, che verranno eseguiti in parallelo. Quindi almeno la decompressione e la compressione verranno eseguite in parallelo.
bzip2l'uso della CPU sminuisce gunzipquello, quindi in pratica il parallelismo che ottieni qui è minimo. Non dover fare l'IO del disco è comunque bello!
Il parallelo GNU ( http://www.gnu.org/software/parallel ) potrebbe essere un'opzione se hai più core (o anche più macchine):
ls *.gz | parallel "gunzip -c {} | bzip2 > {.}.bz2"
Leggi il tutorial / la pagina man per dettagli e opzioni.
Quello che stai attualmente facendo è la tua scommessa migliore. Non è disponibile uno strumento di conversione e il tentativo di bzip2 di un file già compresso non è in realtà un'opzione, poiché spesso ha effetti indesiderati. Poiché l'algoritmo è diverso, la conversione implicherebbe il recupero dei dati originali indipendentemente. A meno che ovviamente il gzipping non sia stato un passaggio nel processo bzip2, in cui purtroppo non lo è.
gzipusa Leimpel-Ziv 77, mentre bzip2usa Burrows-Wheeler. Diversi algoritmi, temo.
Occasionalmente, devo fare la stessa cosa con i file di registro. Comincio con i file * .gz più piccoli prima ( ls -rS), gunzip e poi e bzip2 singolarmente. Non so se è possibile dirigere l'uscita gunzip direttamente sull'ingresso bzip2. Il comando bzip2 è molto più lento durante la compressione rispetto a Gunzip durante la decompressione che potrebbe consumare memoria e scambiare spazio sull'host.
Miglioramenti o suggerimenti sono i benvenuti. Ecco la mia unica fodera:
for i in $(ls -rS *.gz | sed 's/\.gz//'); do gunzip ${i}.gz; bzip2 -9 ${i}; done
Se ne hai più di un paio, dai un'occhiata all'articolo LJ con un bel script di shell.
http://linuxgazette.net/123/bechtel.html
7zip migliora la compressione ed è multi thread.
Ho dovuto farlo pochi minuti fa:
find . -name "*.gz" | perl -pi -e 's/\.gz$//g;' | xargs -n1 ./rezip
Dove rezipsarebbe definito come:
#!/bin/bash
gunzip -v $1.gz && bzip2 -9v $1
Facoltativamente, puoi anche renderlo multi-thread utilizzando -Pun'opzione con xargs, ma fai attenzione con quello. (Inizia in basso!)
pbzip2menzione. Nel caso in cui il collegamento non venga caricato per nessun altro, ecco la pagina del progetto e la pagina man .