Subject: Re: overlap, was Re: Work-in-progress "wedges" implementation
To: Jason Thorpe <>
From: Bill Studenmund <>
List: tech-kern
Date: 09/24/2004 18:40:14
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 24, 2004 at 06:22:10PM -0700, Bill Studenmund wrote:
> 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=
> > 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 wedge=
> know both who their parent wedge (if any) is and who their device is? If=
> 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=
> would be the comment for sc_offset would need to change to indicate that=
> the offset's relative to the device.
> I even think the wedge overlap code will work right. The only thing that=
> might need work would be code to make sure a wedge is within its parent,=
> which would need to take into account a parental sc_offset value.

I'm wrong about this. The loop to look for overlaps would need to be
changed a little. &pdk->dk_wedges would need to be either the parent
disks's wedges (for a top-level wedge) or the parent wedge's child wedges
(for a subwedge). The loop still is fine, we just have to be particular
about what we look at.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)