Ciclo Herramientas gnu/linux (V): pbzip2 y pigz

Hoy comentando con un compañero un filesystem (una partición) que se estaba quedando sin espacio, le he indicado que usase el pbzip2, que lo había dejado yo instalado hace unos días por el mismo problema (y unos ficheros de log enormes).

La verdad es que la teoría es bastante simple, ya que lo único que añade es la opción de paralelismo (pbzip2) sobre bzip2, pero el resultado es bastante impresionante si no quieres esperar a que termine la compresión para irte a casa:

[cc lang=”bash”]
[SERVER02].root:/logs/common/core > time bzip2 -9fv core-2559-1321322015
core-2559-webseald-1321322015: 22.662:1, 0.353 bits/byte, 95.59% saved, 638181376 in, 28161115 out.

real 0m56.240s
user 0m55.379s
sys 0m0.850s
[/cc]
vs
[cc lang=”bash”]
[SERVER02].root:/logs/common/core > time pbzip2 -9fvp16 core-2559-1321322015
Parallel BZIP2 v1.0.5 – by: Jeff Gilchrist [http://compression.ca]
[Jan. 08, 2009] (uses libbzip2 by Julian Seward)

# CPUs: 16
BWT Block Size: 900k
File Block Size: 900k
——————————————-
File #: 1 of 1
Input Name: core-2559-webseald-1321322015
Output Name: core-2559-webseald-1321322015.bz2

Input Size: 638181376 bytes
Compressing data…
——————————————-

Wall Clock: 4.103929 seconds

real 0m4.106s
user 0m55.404s
sys 0m0.923s
[/cc]

En este caso lo que se comprime es un core dumped de un proceso interno y la diferencia está clara (aún usando solo 16 cores de los 64 de la máquina).
Eso sí, si hay un sistema de monitorización muy sensible por medio, puede que salte alguna alarma.

EDIT: Añado pigz que aunque soy fan de bzip2, gzip se usa de manera mucho más habitual…