Re: OFFTOPIC: Re: bzip2 for kernel dists?

Hans Lermen (
Mon, 15 Dec 1997 16:20:22 +0100 (MET)

On Mon, 15 Dec 1997, Mike Kilburn wrote:

> > Hmm.. I just tried bzip2ing vmlinux.. Not a big improvement.
> Big is a relative term. If you are 20K short of including something you want
> then 60K extra is big. Also look at what you save for the compressed root
> file system not just the kernel image.

You should look more closely on what you _real_ win, then you'll see its not
worth the work.

- You have to use the smallest buffersize for bzip2 (option -1), which
will nevertheless need a buffer of 100K. Hence, forget it for zImages.
For a bzImage (which anyway is far away from reaching its limits),
I tested it and got these sizes for the 'tmppiggy' after compression:

477424 Dec 15 15:38 /tmp/3871piggy.bz2 (bzip2 -9)
497139 Dec 15 15:39 /tmp/3871piggy.bz2 (bzip2 -1)
508444 Dec 15 15:35 /tmp/3871piggy.gz (gzip -9)

Seeing it? You win 10(30)K but have to supply a buffer of 100(900)K.

- Currently for zImages, as decompression proceeds, the memory
holding the zImage itself is used as buffer. With bzip2 you can't do
such tricks, because you need the buffer as _one_ big piece.

- You have to rewrite (and test!!!) linux/lib/inflate.c
( not sure this is a stabilizing factor )

- you'll force all people, who want to compile the kernel to have
bzip2 handy (currently not the case)

- ... and (as was stated already) bzip2'ed decompression will be
way to slow for a booting process.