cvs commit: src/sys/i386/conf GENERIC src/sys/alpha/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/amd64/conf GENERIC src/sys/pc98/conf GENERIC

Sean Chittenden sean at chittenden.org
Tue Dec 9 16:19:13 PST 2003


> >On Mon, Dec 08, 2003 at 11:00:20PM -0800, Sean Chittenden wrote:
> >
> >>... Moving from gzip to bzip2 for the base files reduces the
> >>current size of the base files by about 13-22%.
> >
> >I've been trying to move us to bzip2 for the base distribution files
> >since 4.6 (2 years now).  RE has blocked it before ...
> 
> Two observations:
>  1) bunzip2 requires almost 4MB of memory,
>     compared to gunzip's 600KB.

You must be talking about RAM and not disk space.

% du -h /usr/bin/bzip2 /usr/lib/libbz2.so.1
 26K    /usr/bin/bzip2
 62K    /usr/lib/libbz2.so.1

A few notes on RAM consumption:

*) Kiss the notion of getting stock FreeBSD to run on your tipped out
   8086 w/ 4MB of RAM.  :) Last I heard, base FreeBSD required 8MB of
   RAM.  With a 128MB stick costing ~$20, I'm hard pressed to scrounge
   up any sympathy for those trying to run the latest and greatest on
   the oldest and most skanky.  For the 8MB machines out there,
   however, there's the -s switch to bzip2 that reduces the runtime
   size by about 50% down to ~2300K.  man bzip2

*) For those folks, myself included, who use FreeBSD on
   devices... we're not using bzip2 on them and aren't about to use a
   CD to install an OS onto an EPROM.  :)

>  2) bunzip2 is about 10x slower than gunzip on my system.
>  (Decompressing the openoffice tarball: 42s vs. 4s)

10% speed vs. 20% disk on install CDs.  *shrug* With CPUs getting
faster and the standard ISO image still being a CD (no gripes from the
DVD users in the crowd!) that's confined to ~660MB, I'd say space
requirements win out.  I think speed of install only matters on TV
spots when we're watching Mark Murray install a complete FreeBSD
server in 3min (note, 120% of 3min is about 3.5min... not catastrophic
loss of performance for what is essentially a one time operation).
For the extra space (potentially up to ~85MB-145MB), I think the 30sec
is worth it.  Oh, and aren't we already using bzip2 for the packages?
Given that's the bulk of the time that would be spent on installations
for desktops, doesn't that make this a rather mute point?

> Switching to bzip2 format could significantly slow installs and/or
> boost minimum memory requirements.

Eh, perspective... it's not that bad.

> Has anyone built a set of bzip2 install CDs and measured
> the time hit and/or memory requirements?

No, but here's the sh script that'd give you the data w/o building a
release:

cat base.[ab] > base.gz
gunzip -c base.gz > base
bzip2 -9c base > base.bz2
/usr/bin/time /usr/bin/gunzip -c base.gz > /dev/null
/usr/bin/time /usr/bin/bunzip -c base.bz2 > /dev/null
/usr/bin/time /usr/bin/bunzip -sc base.bz2 > /dev/null

-sc

-- 
Sean Chittenden


More information about the cvs-src mailing list