--5UGlQXeG3ziZS81+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 22, 2004 at 01:26:34PM -0700, Jason Thorpe wrote:
>=20
> 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.=
=20
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
dkwedge_info.

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=
=20
fine.

Thoughts?

Take care,

Bill

--5UGlQXeG3ziZS81+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBUhDgWz+3JHUci9cRAmtbAJwPwPfgY4UXepHqb2gWshqGnXcDRQCcCEpE
KQ1rlpCwhDctn1gW6abNfSc=
=Gmgj
-----END PGP SIGNATURE-----

--5UGlQXeG3ziZS81+--