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

On Thu, Sep 30, 2004 at 10:42:28AM +1000, Daniel Carosone wrote:
> On Wed, Sep 29, 2004 at 02:57:44PM -0700, Bill Studenmund wrote:
> > On Mon, Sep 27, 2004 at 10:16:53AM +1000, Daniel Carosone wrote:
> > > Other random useful ideas, both of which probably belong in the
> > > userspace label-parsing-wedge-creating tools:
> > >=20
> > >  - a implied wedge for "unpartitioned space", though perhaps it
> > >    shouldn't be usable as a filesystem.
> >=20
> > Do we really need this? Would it be enough for the raw-disk driver(s) t=
o=20
> > respond to "wedge" ioctls as if the whole disk were one wedge?
>=20
> My thinking went like this: I have a pc with an MBR partition table,
> with a windows partition taking up 1/3 of the disk.  I want to install
> NetBSD. If a wedge were created for the remaining 2/3 of the disk, I'd
> have something concrete to talk about when telling tools to fold that
> wedge into the various label formats i need to create/adjust.

I think that what you're proposing isn't needed, and what you want to do=20
can already be done in what we're talking about.

In the case you're talking about, the first thing you'd do is create a=20
NetBSD MBR partition, probably taking up 2/3 of the disk. _Then_ you would=
=20
get a wedge for that 2/3 of the disk, and you could sick the NetBSD=20
disklabel tools loose on that space.

> Extend that to more complex partitioning schemes, for various gaps,
> and it becomes more useful.

I don't think so. The only time we need to write into unallocated space is=
=20
when we are partitioning a new (or zeroed) disk. Or when you're later=20
adding the NetBSD MBR partition. All the other times I think you'll=20
actually be writing into some already-allocated wedge.

> Oh, I'm not advocating changing the filesystems; nobody cares about
> the few missing blocks.  But at the moment, access to the wedge
> containing the filesystem also implies access to the partition table
> data - which may describe partitions beyond the wedge in question.
> Likewise, having the filesystem block device open can in some cases
> prevent access to the label sector or boot blocks when you need it.
>=20
> If there were a special wedge for access to these sectors, access
> controls could be enforced properly in both of these scenarios.  If
> overlapping wedge semantics were defined appropriately, the existence
> of the smaller wedge might prevent access to these sectors via the
> larger, even though they form part of its address space for offsets.

While we could do that, I think that'd make things difficult.

The main difficulty is that we'd have to 1) create the other wedge (not=20
hard, but it breaks the simplicity of what we're doing), 2) permit=20
simultaneously-open overlapping wedges (something we did NOT envision),=20
and 3) mean that not all of a wedge is writable. Right now, the idea is=20
you get to write all of it at once.

> Finally, there are cases with nested logical drive layers (raidframe
> comes to mind) where these offsets and skips can become hard to
> calculate; defining a label wedge seems like a good way to avoid
> building these calculations and knowledge into multiple tools. The
> wedge can communicate the results.

Huh? All the tools need to worry about is, "I have a wedge and I partition=
=20
it" or "I have a disk and I partition it."

Layered disk devices, like raid devices, hide all of their calculations;
there's no way a tool would ever need to duplicate them. The kernel and=20
thus all the tools just see another disk.

Take care,

Bill

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

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

iD8DBQFBXJOSWz+3JHUci9cRAkbpAJ9JOdICv3Z7wQAm+axpBFpzZrGkDgCfZnG0
vFvH+iQTJ5LjfLngiJelxbk=
=4jBe
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--