Subject: Re: Work-in-progress "wedges" implementation
To: Daniel Carosone <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/30/2004 16:15:30
Content-Type: text/plain; charset=us-ascii
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.
> > Do we really need this? Would it be enough for the raw-disk driver(s) t=
> > 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.
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=
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=
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.
> 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=
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----