Subject: Re: overlap, was Re: Work-in-progress "wedges" implementation
To: Jason Thorpe <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/24/2004 18:22:10
Content-Type: text/plain; charset=us-ascii
On Fri, Sep 24, 2004 at 05:30:31PM -0700, Jason Thorpe wrote:
> On Sep 23, 2004, at 10:15 AM, Bill Studenmund wrote:
> >Oh, I thought wedges had a starting offset which was relative to the
> >underlying device.
> 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=
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=
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):
> # size offset fstype [fsize bsize cpg/sgs]
> a: 294250496 16386300 4.2BSD 4096 32768 64 # (Cyl. 1020 -=
> b: 2098948 310636796 swap # (Cyl. 19336*-=
> c: 296349444 16386300 unused 0 0 # (Cyl. 1020 -=
> d: 312735744 0 unused 0 0 # (Cyl. 0 -=
> e: 16386237 63 NTFS # (Cyl. 0*-=
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=
wedge for 'a' and 'b'. It would not add a wedge for 'e' as 'e' is outside=
of the parent wedge.
So we'd have these wedges:
Start Length Type Added by Parent
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,=
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.=
> "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=
Note: I do realize that to read this disklabel, we will execute a read for=
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
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=
(*) 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=
or not (parent wedge name !=3D "" or not).
Does that make sense?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----