Subject: Re: overlap, was Re: Work-in-progress "wedges" implementation
To: Bill Studenmund <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 09/22/2004 17:11:59
Content-Type: text/plain; charset=US-ASCII; format=flowed
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
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 :-)
> 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"
partitions, because it needs to set the MBR partition type correctly.
You also kind of want some way to tell a wedge "go explore for more
wedges" or not, based on the parent wedge's partition type. I don't
think it's a good thing to willy-nilly go explore for sub-wedges every
> 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
There would be no need for that. There's a reason that a wedge is
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
disk drivers use.
> The one remaining issue I can see is that we would thus not make a
> 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
See, now it's tricky... in the "BSD disklabel inside MBR partition"
case, the block numbers in the BSD disklabel are absolute, not
MBR-partition-relative. So you'd have to search up the tree to figure
out how to create those. I haven't thought of a good way to handle
-- Jason R. Thorpe <firstname.lastname@example.org>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----