Subject: Re: overlap, was Re: Work-in-progress "wedges" implementation
To: Jason Thorpe <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 09/23/2004 10:15:57
Content-Type: text/plain; charset=us-ascii
On Wed, Sep 22, 2004 at 05:11:59PM -0700, Jason Thorpe wrote:
> On Sep 22, 2004, at 4:55 PM, Bill Studenmund wrote:
> > 3) What do we want to do about overlapping wedges? The patch
> > currently doesn't permit them, which makes a lot of sense
> > at first glance - we want any block on the disk to be opened
> > by only one wedge at a time. However there's the MBR format.
> > It quite happily makes recursing partition entries.
> > If each MBR partition were its own wedge, then it'd be
> > trivial to have partitioning tools deal with extended
> > partitions. We just create a wedge for the extended partition
> > then sick the tools on that wedge. Then make an extended
> > partition in there, and repeat. This behavior might also
> > help import things like FreeBSD slices.
> No problem. Overlapping is only disallowed on a given parent. So, to=20
> do what you're suggesting, a wedge would be the parent of the recursive=
> wedges, not the actual disk, therefore no overlap would actually occur.
> That said, right now wedges can't be parents of other wedges. That was=
> a conscious decision on my part. Maybe we can revisit that late :-)
Ok. We can revisit this later. However we don't seem to have a way to=20
prevent simultaneous access to both parent and child wedges. But we can=20
add that when we add wedge paternity.
> > The problems though are: a) we now have wedge overlap, and
> > b) I'm not really sure how one would name the MBR wedges.
> > Only partitioning tools would really care about them.
> Your partitioning tools still have to know they're creating "extended"=20
> partitions, because it needs to set the MBR partition type correctly. =20
> You also kind of want some way to tell a wedge "go explore for more=20
> wedges" or not, based on the parent wedge's partition type. I don't=20
> think it's a good thing to willy-nilly go explore for sub-wedges every=20
Oh, my thought would be that whatever created the wedge for the extended=20
partition would, just after creating the wedge, trigger the recursive=20
So we only go exploring under controlled circumstances.
> >Hmmmm... Maybe the thing to do is add the concept of parent and child
> >wedges. Add a list (TAILQ?) head and entry point to struct=20
> There would be no need for that. There's a reason that a wedge is=20
> presented to the kernel as "just another disk" :-) If I chose to allow=
> it, it could simply use the same discovery mechanism that all other=20
> disk drivers use.
Oh, the lists were more for preventing opening both a wedge and its=20
children. When we go to open a partition, we look to see if any of its=20
children or their children are open and also look to see if a parent is=20
> >The one remaining issue I can see is that we would thus not make a=20
> >for a Disklabel partition that is outside the NetBSD MBR space. However
> >all the times I've seen us want to do that, we are bringing some other
> >partition (like an msdos or Linux one) into the NetBSD partitioning
> >scheme. Since we now can find the other partition natively, I think=20
> See, now it's tricky... in the "BSD disklabel inside MBR partition"=20
> case, the block numbers in the BSD disklabel are absolute, not=20
> MBR-partition-relative. So you'd have to search up the tree to figure=20
> out how to create those. I haven't thought of a good way to handle=20
> this yet.
Oh, I thought wedges had a starting offset which was relative to the=20
underlying device. And then wedges short-circuited to the underlying=20
device (so that nesting partitions didn't end up nesting io processing).=20
So all the offsets of a child-wedge would both be 1) absolute in the=20
underlying device and 2) within the parent wedge. So BSD dislabel=20
partitions could just directly become wedges (within the NetBSD MBR=20
partition). MBR partitions would need a little help in that they are=20
relative to the parent partition, so partitions in an extended partition=20
would need to have its offset added in. But that shouldn't be hard.
Of course then this raises the question of what to do on really-old-style=
BSD layouts where partitions g & h overlapped d, e, and f...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----