Subject: Re: wedges vs. not-quite-wedges, was > 1T filesystems, disklabels, etc
To: Bill Studenmund <wrstuden@netbsd.org>
From: Greg Oster <oster@cs.usask.ca>
List: tech-kern
Date: 12/19/2002 19:54:38
Bill Studenmund writes:
> 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?

?? Ok, now I'm confused.  Where did I say that??

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

Only to (try to) make the point that the native disklabel on a given arch may 
not be flexible enough to allow a consistent implementation of wedges across 
all platforms.  And if that would force us into using a different label scheme, 
then I'd like to see that scale to LVMs... (yes, I know.. I read the whole 
message before writing 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 i
> n
> > > the native label, so we have to use a label that can keep other OSs out o
> f
> > > our stuff. :-)
> >
> > And all we need for that is a marker that says "this chunk of the disk is u
> sed
> > 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 scal
> able
> > > > towards LVM-like metadata".  That is, let's break free from the old dis
> klabel
> > >
> > > 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 addin
> g
> > 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.

My impression was that there was going to be enough new stuff happening here 
that we could at least have LVM's in the back of our minds when working on 
this stuff; especially if we are changing the contents of the native labels. 
If we arn't actually mucking with the layout/content of the labels, but only 
with the how they are read/written, that's much less interesting for me :)
 
> > > 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 relat
> ed
> > 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?

Ultimately, yes.

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

I can agree with that.  I have a reasonable idea of what I'd like to see for 
RAIDframe (which is why I "shot high" and went all the way to scalling to 
LVMs), but it doesn't sound like the labels are changing in any way that 
RAIDframe can make use of for storing it's metadata, so I'll not bring 
that up here :)

So as long as RAIDframe can still autoconfig a partition/wedge/whatever, 
I'll be happy (and quiet :) ).

Later...

Greg Oster