Date: Mon, 8 Dec 2003 23:00:20 -0800 From: Sean Chittenden <sean@chittenden.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: cvs-all@freebsd.org Subject: Re: 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 Message-ID: <20031209070020.GC59494@perrin.nxad.com> In-Reply-To: <20031208190305.GA956@cirb503493.alcatel.com.au> References: <200312072352.hB7Nqsw6011333@repoman.freebsd.org> <20031208190305.GA956@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031209070020.GC59494>