On Thu, 19 Dec 2002, Greg Oster wrote:

> 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 don't think so. I'd expect that whatever is the eqivalent of lv# for an
LVM system will be specifiable as a root device, just as you can specify a
raidframe partition.

> 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:

Please note: I think the below is fine IN TERMS OF HAVING AN LVM ON TOP.

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

Two questions. 1) I'd rather expect we'd really mark it, "NetBSD LVM".
:-) 2) Why do we need a partition? What do say Veritas or IBM's LVMs do?

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

I think it is VERY DANGEROUS for us to refer to spaces outside of the
"NetBSD" space. While we do it now in disklabels, as we migrate to more
indirect allocation methods, I think it will be harder to keep things in
sync.

If we want to co-exist with other partitioning schemes, THAT'S COOL. If we
want an LVM system, THAT'S COOL too. But let's NOT MIX THEM.

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

Why do we need to get NetBSD-specific stuff out of the "native disklabel"?

I'd think it'd be easier to just teach all flavors of NetBSD about all
disklabeling schemes we understand. 'cause there will be times when we
care about non-NetBSD-specific stuff on non-native disks. Making a common
library to understand other disklabel schemes is the only way to fix that,
and once we do that, we can also deal with NetBSD-specific stuff. :-)

Take care,

Bill