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]

> >scottl      2003/12/07 15:52:54 PST
> >
> >  FreeBSD src repository
> >
> >  Modified files:        (Branch: RELENG_5_2)
> >    sys/i386/conf        GENERIC 
> >    sys/alpha/conf       GENERIC 
> >    sys/sparc64/conf     GENERIC 
> >    sys/amd64/conf       GENERIC 
> >    sys/pc98/conf        GENERIC 
> >  Log:
> >  Don't build a kernel.debug for the release.
> 
> Out of interest, why not?  The first request for additional
> information after a panic report is virtually always to perform a
> backtrace against a debug kernel to get line numbers.  IMHO, having
> a debug kernel supplied with -RELEASE would seem very useful for
> people who don't rebuild their kernel.  Note that, last time I
> checked, it is not at all clear that '-g' does not change the
> generated code so you can't guarantee to be able to do a '-g' build
> after the fact and generate a traceback.
> 
> I'm not suggesting that kernel.debug has to be part of CD 1, but I
> believe it would make a worthwhile addition to (eg) the live
> filesystem CD.

Not that I'm particularly involved with this aspect of things, but I
just burnt myself a CD image for the data center and found that I
didn't have room for the 50+MB debug kernel and debug modules, but I
was stunned at how well it did compress (~69%).

% bzip2 -9c kernel.debug > kernel.debug.bz2
% compress -c kernel.debug > kernel.debug.Z
% gzip -9c kernel.debug > kernel.debug.gz
% du -h kernel.debug*
 27M    kernel.debug
 15M    kernel.debug.Z
8.3M    kernel.debug.bz2
 10M    kernel.debug.gz

Given the time difference between unzipping between bzip2/gzip (pretty
small, esp compared to the time required to bzip2/gzip something), I'm
surprised we don't make more liberal use of bzip2 on our releases.  I
know packages are the big space consumer, but 3% here and there (20MB
of 660MB) adds up.

Moving from gzip to bzip2 for the base files reduces the current size
of the base files by about 13-22%.

% du -k subin*
10080   subin
1824    subin.bz2
2224    subin.gz

% du -k ssys*
76320   ssys
12336   ssys.bz2
15808   ssys.gz

% du -k base*
138944  base
41552   base.bz2  70% of original size, 6MB smaller
47824   base.gz   65% of original size

And compressing base.mtree saved over 600K which seems like an easy win
given it's as simple as changing:

	cat base.mtree.bz2 | mtree ${MTREE_FLAGS}

to:

	bzcat base.mtree.bz2 | mtree ${MTREE_FLAGS}

% du -h base.mtree*
768K    base.mtree
130K    base.mtree.bz2

Just some food for thought... there's more blood to be squeezed from
this turnip.  -sc

-- 
Sean Chittenden