Why we don't use bzip2 in sysinstall/rescue?

[Giorgos Keramidas]

On 2007-08-19 16:46, Jeff Roberson <jroberson at chesapeake.net> wrote:
>On Fri, 17 Aug 2007, Oliver Fromme wrote:
>>LI Xin wrote:
>>> As a side note.  For networked installation, using bzip2 would
>>> reduce traffic by ~11%.
>>
>> And increase local installation time by 900% (except maybe on
>> high-end machines).
>>
>> I just tested extracting a 10 MB .bz2 file to /dev/null on our 800
>> MHz server:  It took 57 seconds.  Recompressing the result to .gz,
>> extracting that took only 5 seconds.  The installation data is
>> roughly 30 times that much.
>
> I tried this on my 1.8ghz pentium M laptop with 5.6MB of jpg data.
>
> I did:
>
> tar cvf foo.tar foo
> cat foo.tar >> /dev/null
> time bzip2/gzip foo.tar
>
> I removed and recreated the tar each time.  The cat was to make sure
> it was in cache, although it certainly was from the creation step
> before.
>
> Anyway, the results are:
>
> bzip2
> 2.452u 0.026s 0:07.65 32.2% 92+3227k 5+43io 0pf+0w 1849c/6w
>
> gzip
> 0.539u 0.020s 0:01.75 31.4% 109+3268k 2+44io 0pf+0w 493c/3w
>
> So only 4.6x slower here although my processor is twice as fast.
> Still, I imagine local installation is actually dominated by transfer
> rates from the cd and file creation time on the new volume.  Making
> lots of little files is relatively slow, and I bet we don't use
> softupdates on the target volume during sysinstall.  A better test
> would be to actually extract a bzip and a gzip from a cd to a local
> filesystem and measure the times.

My own tests with compressing stuff yielded similar results to what
Oliver and Jeff have.  bzip2 results in 5-10% more compression, but
at the expense of 4x or 5x CPU time to compress everything.

A more interesting test would be what Jeff suggests, i.e. to find out
what the CPU-time penalty of *decompressing* bzip2 archives would be,
and writing them back on disk.

- Giorgos