Subject: Re: tiny ramdisk too big in i386 release
From: David Laight <email@example.com>
Date: 02/26/2003 18:15:11
On Wed, Feb 26, 2003 at 05:32:35PM +0000, Patrick Welche wrote:
> It's just grown too big for a release:
> /usr/src/tools/obj.i386/tools.NetBSD-1.6P-i386/bin/nbmakefs -t ffs -B le -s 1480k -F work.spec -N /usr/src/etc -o bsize=4096,fsize=512 -o optimization=space,minfree=0,nsectors=1,ntracks=128 -f 10 -f 14 ramdisk-tiny.fs.tmp work && mv -f ramdisk-tiny.fs.tmp ramdisk-tiny.fs
> nbmakefs: `work' size of 1523712 is larger than the maxsize of 1515520.
I went through all those hoops earlier in the week.
My investigation showed:
1) It is very hard to determine what was in the last set of working
boot floppies, and exactly how large it was.
This would be useful to find out whether the size increase was
necessary - or whether it might be better to shrink the offending
2) The ramdisk sizes could probably be significantly larger, since
the additional (unused) space would be compressed and take up
almost no space in the final boot image.
(This would also alleviate problems with space in /tmp when the
system has booted)
3) There is actually quite a lot of space in all but one of the
floppy images (one of the 1.2M floppies only has 2k free).
4) The cunched binary could have it's .ident and (probably) .note
sections removed. Saving about 60k before compression.
5) The crunched binary doesn't have dependancies against the source
files that generate it, so it doesn't tend to get rebuilt, so
no one discovers quickly that it is too big.
(/rescue/* doesn't get rebuilt either)
6) The crunched binaries are not built by a normal build.sh, so
many developers tracking current won't build them.
7) The ramdisk image size has to match the size of the gap in the
kernel. These are set in two different places, but have to match.
David Laight: firstname.lastname@example.org