Subject: overlap, was Re: Work-in-progress "wedges" implementation
To: Jason Thorpe <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 09/22/2004 16:55:12
Content-Type: text/plain; charset=us-ascii
On Wed, Sep 22, 2004 at 01:26:34PM -0700, Jason Thorpe wrote:
> Known issues:
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=20
partitions. We just create a wedge for the extended partition
then sick the tools on that wedge. Then make an extended=20
partition in there, and repeat. This behavior might also
help import things like FreeBSD slices.
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.
Hmmmm... Maybe the thing to do is add the concept of parent and child=20
wedges. Add a list (TAILQ?) head and entry point to struct dkwedge_softc.=
Wedges must not overlap their siblings, and must fit within their=20
"parent". Top-level wedges have the disk as a parent. And for a wedge to=20
be openable, neither its parents nor its children must be open. A layout=20
like this means that checking for other partitions is only O(recursion=20
level) not O(# partitions). Parents of course have to be on the same disk.
Since wedges are named, we need only add a "parent name" field to struct=20
The one remaining issue I can see is that we would thus not make a wedge=20
for a Disklabel partition that is outside the NetBSD MBR space. However=20
all the times I've seen us want to do that, we are bringing some other=20
partition (like an msdos or Linux one) into the NetBSD partitioning=20
scheme. Since we now can find the other partition natively, I think we're=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----