Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uunet!munnari.oz.au!bruce!goanna!minyos!chudich!rcodi
From: rcodi@chudich.co.rmit.oz (Ian Donaldson)
Newsgroups: comp.unix.wizards
Subject: Re: 4BSD file system structure
Message-ID: <1602@minyos.xx.rmit.oz>
Date: 14 Nov 89 02:25:14 GMT
References: <3410@netcom.UUCP> <20643@mimsy.umd.edu>
Sender: news@minyos.xx.rmit.oz
Lines: 109

chris@mimsy.umd.edu (Chris Torek) writes:
>In article <3410@netcom.UUCP> hinton@netcom.UUCP (Greg Hinton) writes:
>>If so, doesn't the presence of the boot block throw things off?

I've always wondered why the boot block actually needs to be in
the filesystem at all?

I've set up a small system where the 'b' partition contains vmunix,
and /vmunix is really a block special file with permissions 644 that
points to that partition.

This way, all the PROM monitor need do is read the disk label from partition
'a', then read vmunix from partition 'b'.  vmunix then boots, and the
root lives on partition 'c' and the swap on 'd'.

ie: this sort of partition layout

	a:  label, bad block map if needed, substitute good blocks
	b:  vmunix  (the default bootable kernel)
	c:  root
	d:  swap
	e:  another vmunix if necessary
	f:  another vmunix if necessary
	g:  tmp
	h:  usr
	i:  other
	j:  other
	   etc

This has the advantages that:
	1) The primary boot program on disk is eliminated, and
	   also the secondary boot (usually /boot if it exists) is eliminated.

	   Also the silly size limitation of 8k bytes is eliminated too due to
	   the amount of space the filesystem allowed for it, usually
	   requiring a secondary boot program, /boot.  
	   
	   On SunOS 3.x, the primary boot program read /boot by interpreting 
	   the filesystem.  Fine.
	   
	   On SunOS 4.x, /boot doesn't know how to read the filesystem 
	   (probably because it would have overflowed the 8k size limitation) 
	   and has to have a hard-coded list of block numbers in it, set there 
	   by installboot(8).  This sucks to say the least.  When you move 
	   or copy to /boot you need to rerun installboot(8).  Not that 
	   you do this often however...)

	2) the prom monitor code only needs to know to read partition b
	   after reading the label to determine where it starts

	3) the label is always at absolute sector 0 and contains the
	   partition info

	4) vmunix boots blindingly fast as the monitor reads it
	   (eg: on a 68000/st506 combination it takes 2-3 seconds to
	   get it running!  This compares with about 10-15 seconds it
	   takes to read the various boot programs and vmunix on a Sun-3)

	5) makes the system more portable.  You don't need some
	   non-portable assembler code for the primary boot, and you don't need
	   some extra filesystem dependent code for the secondary boot,
	   enabling booting to be independent of the root filesystem type.
	   (4.4 bsd is even rumoured to have support for multiple filesystem
	   types)

This has the disadvantages that:

	1) /vmunix is not a regular file.  Not a real problem, but
	   purists may object.   Programs that need to know the
	   size of /vmunix won't be able to use stat(2) to find
	   this out.  However, nlist(3) doesn't need this information, so
	   programs like ps(1), pstat(1), w(1), size(1) won't need to 
	   be changed.

	2) the size of the partition to hold vmunix must be estimated
	   prior to installing.  About a megabyte is sufficient
	   in most cases for most kernels.  It is tunable in the
	   partition table anyway.

	3) you may need more than 8 partitions per disk do set your system up
	   (this isn't hard to change in the drivers)

	4) juggling the kernel you boot is not as simple as mv'ing the
	   name.  You need to copy into the device.  This is not
	   too difficult really.  You could even have a parameter
	   in the label that specifies an alternate default boot
	   partition, but programs such as ps(1) would need to read
	   /vmunix still, necessitating some sort of "special" indirect 
	   device that points to the boot partition if you want to do
	   it properly.

My guess that the 4.[23]BSD way of putting the boot block into the first
part of the filesystem stems from the fact that:

	1) at the time that the FFS was introduced, there was no
	   4BSD disk labels (except from some vendors such as Sun),
	   and the VAX prom may have booted VMS this way (I'm not
	   sure about this).  Partitions were hardcoded in the
	   drivers and thus more difficult to change.
	   The 4.3-tahoe release added the labels.

	2) there might be a limitation in the bootprom for the VAX
	   that prevents such a layout (I don't know, but it doesn't
	   sound like something that isn't easily solvable with
	   a prom change)

Care to comment Chris?

Ian D