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

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) to=
=20
> respond to "wedge" ioctls as if the whole disk were one wedge?

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.

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

> >  - a very small wedge for the actual sector(s) occupied by the MBR or
> >    other partition tables, to disabiguate update access to this data and
> >    avoid various special "skipping first block" schemes in filesystems
> >    etc.
>=20
> Too late. The file systems already have this skip space. To not do so
> would mean changing the fs layout. They also need to retain something, as
> they also have to support having boot code in the front of the fs.

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.

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.

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.

Anyway, just random ideas in case they're useful.

--
Dan.

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

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

iD8DBQFBW1Z0EAVxvV4N66cRAm3JAJ0ekQcCPY5bo7FwvTxgV1XPc7dXqQCffXhI
mlxIuG0J8aVJUxoHy1D57Og=
=1hOG
-----END PGP SIGNATURE-----

--XVddTWRQMr0ODUnD--