On Thu, 19 Dec 2002, Greg Oster wrote:

> Bill Studenmund writes:
> > On Thu, 19 Dec 2002, Greg Oster wrote:
> >
> > For that list of things, I think it's fine for us to reach outside the
> > NetBSD space. I'm sorry, I was reacting more from the idea of reaching
> > outside the NetBSD space to get at say the FreeBSD partitions. While I
> > think we should get at them, they aren't part of an LVM system, and we
> > shouldn't try and shoe-horn them into one.
>
> I keep talking about a PV system, not a LVM system.. (i.e. Physical Volume
> system, not Logical Volume Managment).  So while yes, a FreeBSD
> partition might not fit into a LVM, it would (IMO) fit into a PV Management
> system.

?? I'm very confused. Why do you have partitions (note plural) on a
physical volume of an LVM?

> > I don't think "not fitting" will be a concern, since "native" disklabels
> > will have to update themselves to deal with large disks. :-)
> >
> > As for 256 partitions, who in the world will ever use 64 of them?
>
> Ok, so pick an arch that can't even support 64 in it's native label :)
> (can you do 16 partitions in a native Sun disklabel?)

?? Where are you going with this?

> > Yes, but there are other ways to fix it.
> >
> > For one, we need a way to express the side of the NetBSD-specific stuff in
> > the native label, so we have to use a label that can keep other OSs out of
> > our stuff. :-)
>
> And all we need for that is a marker that says "this chunk of the disk is used
> by NetBSD", and some well-defined way of pulling out whatever slice/wedge/
> partition information that might be related to that chunk.
>
> > > I guess I'm leaning towards a "let's make the new labelling scheme scalable
> > > towards LVM-like metadata".  That is, let's break free from the old disklabel
> >
> > Why? Why use LVM-like metadata? If we want an LVM, let's add an LVM!
>
> If we restrict our new labelling scheme to not be able to include the
> meta-data that might be needed to identify a Physical Volume, then at some
> point when we do get a LVM, we're going to have to go "outside the label"
> to get that information.  All I'm suggesting is that we keep the idea of
> eventually getting an LVM in the back of our minds as we're designing this new
> thing, so that we don't do anything that will preclude us from easily adding
> an Physical Volume manager or a LVM in the future.

We aren't making a new labeling scheme. We are making a new way to read
partitions and deal with them.

We aren't making a new labeling scheme.

We aren't making a new labeling scheme.

We probably will be adding a new labeling scheme to read & write, but
that's only related to the fact that we want to deal with disks that won't
fit in the current schemes.

> > Do we have any idea that wedges would be useful for an LVM?
>
> As Physical Volumes, why not?  The trick is just to keep the metadata related
> to that PV outside of the wedge (e.g. in a "label" :) )
> > I mean, come on. What RAID system wants to expose its individual
> > components to userland? The completed RAID sets, yes, but not the
> > components.
>
> Exposed in what way?  For some things (e.g. a failed disk) the RAID system
> needs to be able to tell the user which disk has just died...

But wedges are an abstraction on top of disks. If a PV is dying, you want
to know there's a problem with sd3, not wedge2, don't you?

> I'm shooting for something that scales to LVM's for the simple reason that I
> don't want to see a whole bunch of work done on something, only to have to
> re-do/re-visit a bunch of this when we eventually need to deal with the
> meta-data for Physical Volumes.

I don't think we know enough of what we want for LVMs right now, so I
think this isn't the time to go there.

Take care,

Bill