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

On Fri, Sep 24, 2004 at 05:30:31PM -0700, Jason Thorpe wrote:
>=20
> On Sep 23, 2004, at 10:15 AM, Bill Studenmund wrote:
>=20
> >Oh, I thought wedges had a starting offset which was relative to the
> >underlying device.
>=20
> Wedge offsets are relative to their parent, which in this case is the=20
> underlying disk device (since I have explicitly chosen to disallow=20
> wedges-on-wedges, for now).

How about we make wedge offsets relative to the root disk, and have wedges=
=20
know both who their parent wedge (if any) is and who their device is? If=20
we leave sc_parent as the parent _disk_, then it should all work. Well, I=
=20
think dkstrategy() and dkstart() would need no changing. The only change=20
would be the comment for sc_offset would need to change to indicate that=20
the offset's relative to the device.

I even think the wedge overlap code will work right. The only thing that=20
might need work would be code to make sure a wedge is within its parent,=20
which would need to take into account a parental sc_offset value.

> The problem I am getting at is... take a look at a BSD disklabel on a=20
> PC, where that disk also has an MBR, possibly shared with another OS=20
> (e.g. Windows):
>=20
> #        size    offset     fstype [fsize bsize cpg/sgs]
>  a: 294250496  16386300     4.2BSD   4096 32768    64  # (Cyl.   1020 -=
=20
>  19336*)
>  b:   2098948 310636796       swap                     # (Cyl.  19336*-=
=20
>  19466*)
>  c: 296349444  16386300     unused      0     0        # (Cyl.   1020 -=
=20
>  19466*)
>  d: 312735744         0     unused      0     0        # (Cyl.      0 -=
=20
>  19466*)
>  e:  16386237        63       NTFS                     # (Cyl.      0*-=
=20
>   1019)

Here's what I was expecting would happen for this case. An MBR parser=20
would read the base MBR partition layout, and add wedges for the Windows=20
and the NetBSD MBR partitions. The NetBSD disklabel reader (or the=20
NetBSD-disklabel-in-MBR-reader) would then read the disklabel and add=20
partitions. It'd ignore 'c' and 'd' as they aren't needed. It would add a=
=20
wedge for 'a' and 'b'. It would not add a wedge for 'e' as 'e' is outside=
=20
of the parent wedge.

So we'd have these wedges:

Start		Length		Type	Added by	Parent
sc_offset	  sc_size
       63	 16386237	NTFS	MBR reader	""
 16386300	296349444	NetBSD	MBR reader	""
 16386300	294250496	ffs	NetBSD reader	"#2"
310636796	  2098948	swap	NetBSD reader	"#2"

So everything is there, it's just done a little differently.

Part of what I'm assuming is that any wedge that would be in a NetBSD
disklabel that's outside of the NetBSD MBR partition is there because it's
a duplicate of a partition NetBSD couldn't see before. Since we can now
see it natively, we don't need the duplication. Also, since we now only
look in one place for the partition, any changes are automatically
noticed. Like if you added partitions to a NetBSD disklabel to find Linux
partitions, and then re-did the Linux partitioning; since we now look=20
directly at the Linux partitioning and ignore the NetBSD disklabel clone,=
=20
we find the right partition.

> This disklabel resides inside an MBR, but the partition offsets in the=20
> disklabel are not relative to the MBR partition, they're absolute (i.e.=
=20
> "relative to the beginning of the disk").  This is the problem with a=20
> generalized wedge nesting approach, in which the label inside a wedge=20
> would be presumed to have offsets relative to the wedge.

Ahh! I'm not assuming a wedge partitioning will necessarily have=20
_partition_ offsets relative to the wedge start. Since, as you note, they=
=20
don't.

Note: I do realize that to read this disklabel, we will execute a read for=
=20
block 1 (LABELSECTOR) in the NetBSD wedge.

> I forget ... do MBR Extended Partitions specify absolute offsets, or=20
> offsets relative to the chunk that contains the nested MBR partition=20
> map?

AFAIK they are relative to the containing wedge. So with what I'm=20
describing above, the MBR reader would need to add the parent's sc_offset=
=20
(*) to the start of any wedge it creates. Then things would all work out.

(*) if natural devices respond to the "give me wedge info" ioctl, it can=20
perform the ioclt on the parent then add that sc_offset in. natural=20
devices would report sc_offset (or whatever it's named) as zero.=20
Otherwise, we can still work it out since we know if the parent is a wedge=
=20
or not (parent wedge name !=3D "" or not).

Does that make sense?

Take care,

Bill

--XvKFcGCOAo53UbWW
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBVMhCWz+3JHUci9cRAqJ7AJ49RG2ysNKDIgnESXVzgGQEMu6/KACeO4Vh
/DEi8bjKzL5qksWPrixh6Do=
=RKrq
-----END PGP SIGNATURE-----

--XvKFcGCOAo53UbWW--