From: ftp://sources.redhat.com/pub/bzip2/docs/manual_2.html#SEC7
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642
It's interesting to note that in this case -8 and -9 yield the same
results, but -9 requires more memory at the time of decompression and
compression. I suspect the memory usage statistics will remain constant
for any file (inherent in block sorting), not just the corpus. The
compression results will of course vary depending on the input file.
If memory usage is a concern and small files like initrd are being
compressed, the choice between gzip and bzip2 leans towards gzip. bzip2
only really compresses better than gzip with large blocks (thus high
memory requirements) and on small files like initrd it doesn't make much
of a difference in nominal (non percent) terms.
Prediction by Partial Match (PPM) algorithms are usually very good at
compression, take lots of memory and are very slow. Thus PPM algorithms
would be good to compress an entire initrd file to make the media space
requirements small, but require more memory and CPU time than other
compressors.
The order of the files in the initrd file can make a difference if the run
length or context of the compressor can span multiple files (large block
sizes). I don't know how one could change the order of files in an initrd
file, but I suspect it's like tar, just pass them in a different order.
The order of files would make no difference if files are compressed
independently like squashfs does.
Phillip Lougher:
I'm also not subscribed to debian-boot thus I can't get the threading
right, but you did. I read the mailing list at
http://lists.debian.org/debian-boot and several others on
lists.debian.org.
Would you be willing to try to get squashfs to be made part of the
standard Debian Linux kernel? I'm not sure how, or what the reaction would
be.
I've submitted a request for packaging which you can see at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179672 It's likely that
the Debian Linux kernel maintainers would not include squashfs, but would
suggest that it be made a patch package. If the boot system team finds it
useful enough then maybe that would be enough to have squashfs include in
the Debian Linux kernel.
Drew Daniels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
