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
   item.

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

-- 
David Laight: david@l8s.co.uk