On Tue, 21 Sep 1999, Greywolf wrote:

> [ still need to read that wedge thing...but...]
> 
> Why not have the central disklabel accommodate 16 partitions (hard),
> with the remaining six entries pointing to other partition types at
> other locations on the disk...?

Leo's suggestion was to have one in-core disklabel, which is generated
from reading on-disk disklabels. There's no longer a necessity that
the in-core disklabel be writable by the kernel onto the disk. You're
focusing more on the on-disk layout of the disklabel, which is a specific
subsection of the discussion. :-)

Why do this? Because there are a number of partitioning schemes (the Amiga
one from what I understand, and also the MacOS one) where there's much
more info about each partition than we really want to have the kenrle keep
around. For instance, each MacOS partition takes up one sector on disk.
For the kernel to be able to modify MacoS partition tables, it'd have to
save lots of state. It just seems a lot easier for a userland program to
go mucking around with these partition schemes, and then have the kernel
re-read the disklabel.

> # > My suggestion for the raw-device would be partition zero. Otherwise, what
> # > are you planning to do when we bump to, say, 128 partitions? Move it again?
> # 
> # I don't forsee us ever moving this number again. I think we should get it
> # right now, and leave it alone.
> # 
> # raw == partition 0 would be fine too. I was just thinking of keeping the
> # minor #'s the same for the first 8 partitions, but that's not a big deal.
> 
> Is intel the only port that uses 'd' as the 'whole (Berkeley) disk',
> while others use 'c'?

Right. This is a leftover of how 386BSD supported MBR partitioning.

> In this case, getting it 'right' would probably be one of the following
> two:
> 
> 	1.  Keep 'c' as the default whole disk partition.
> 	2.  Allow the whole disk partition to be moved at will.

Why? Why does the "whole disk" partition have to be encoded in one of the
disklabel partitions? :-)

> (1) makes the assumption that we're going to keep the 'whole disk'
> semantics in the driver, but it also holds with the traditional layout
> of the disk.  Is 'c' usable, actually, as a whole-disk partition at the
> moment, or is that an illegal operation (haven't tried it, don't know)?

It is usable as a whole-disk partition now.

> (2) would require the administrator to provide the location of the whole
> disk to a disklabel(8) command, which could turn out to be guesswork,
> unless we granted explicit permission to access the disklabel through
> any partition on the disk.  This might be confusing to the neophyte,
> and it could well be a PITA to implement correctly.
> 
> [note: my logic is not the greatest, so forgive any fallacious jumps
> I might have made.]

My big question from this discussion is why do we need to have the
whole-disk partition be one of the ones in the disklabel? It made sense
back when disklabels came out (the on-disk label could hold more
partitions than the minor numbers permitted on a disk, and the whole disk
partition had to go somewhere) , but I don't think it's still a necessity. 

Take care,

Bill