Bill Studenmund writes:
> On Wed, 18 Dec 2002, Frank van der Linden wrote:
> 
> > I think I mostly agree with what you're proposing, except that you seem
> > to think that using on-disk partitions excludes 'LVM' type usage that
> > uses config files.
> 
> Yes, I do, for a given disk. If we use a partition editor to lay them out,
> they are partitions, and we should act like it.
> 
> If we want to go the LVM route (and I think WE DO and I'd LOVE it), we
> give the whole disk to the LVM route. My thought is that an LVM'd disk
> would have no defined partitions in the diskpart method.

In LVMland, a simple partition could be a "Physical Volume".  If an LVM'd disk 
has no defined partitions in the diskpart method, then is that going to 
exclude a "boot disk" from participating in an LVM?

I've mentioned this before in a few other places, but what I'd like to see
(e.g. for use w/ RAIDframe) is something like:

 1) The native disklabel looks "however it does" for that arch, and has zero 
or more partitions "marked" as being "NetBSD".  (e.g. On i386, the MBR might 
be the native disklabel with a primary or secondary partition(s) marked as 
being "NetBSD".  Or the current disklabel might be the disklabel.   Whatever.
On Sun's, the existing sun disklabel would be the native label.)  The only 
thing "NetBSD-specific" in a native label is some identification that 
certain chunk(s) of the disk are "NetBSD". 

 2) In each of the chunks marked as being "NetBSD", we put in our own 
wizz-bang fancy slice/wedge/partition/LVM/RAID-labelling scheme.  The 
information stored there might be as simple as offset, size, and type, 
or as complex as a complete RAIDframe component label, or perhaps 
something even more compilicated than that (LVM record of some sort?).
The metadata stored here could refer to any/all blocks/partitions on the disk, 
be they NetBSD-specific or not.

The advantage is that once you get to the "metadata" specified in 2), it's 
consistent across all NetBSD platforms.  The other advantage is that the 
native disklabel now has much less NetBSD-specific stuff in it.  The primary 
disadvantage is that other OS's might have to learn how to grok the NetBSD 
metadata.  But a little "NetBSD metadata" library would take care of that...

Later...

Greg Oster