Subject: Re: Work-in-progress "wedges" implementation
To: Chapman Flack <>
From: Bill Studenmund <>
List: tech-kern
Date: 09/30/2004 17:54:30
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 30, 2004 at 06:56:05PM -0500, Chapman Flack wrote:
> Jason Thorpe wrote:
> > Consider, for example, a partitioning scheme that stores multiple=20
> > copies of its information for redundancy purposes.  GPT is one such=20
> > format.
> How is such a thing accommodated now, if it is?  What is done by code

We don't support GPT right now.

> laying a filesystem into a partition that contains scattered copies of
> GPT information?  Does the filesystem code have to understand GPT?
> Does the driver implement a mapping function so the FS code sees a
> partition of contiguous usable blocks?  If so, could such a mapping
> function be reified as a GPTinfo wedge?  This is not a wedge that
> *overlaps* the larger surrounding wedge, but *interrupts* it.
> Something like the small contiguous MBR wedge at the front would be a
> simple special case.

File system doesn't need to understand GPT. GPT partitions are rich enough=
that we don't need to use on-disk disklabels, so we won't need to shove=20
partitioning info in the same wedge as a file system.

> One favorable argument for such special wedges that I haven't seen
> articulated yet is that, while it's all well and good to hide a lot of
> location and layout information transparently from most of the kernel
> and tools, it is not as good to go so far in transparency that the sysadm=
> has to bend over backward to get the information.  We've probably all kno=
> times (or will know times) when it has suddenly become imperative to be
> able to pin down exactly where a particular file block or data structure
> is living on the disk.  And while those times don't come around often,
> they are usually the last occasions when you want to go on a documentation
> research project to find out just where and how the stuff has been
> allocated.  To know where a particular disk structure lives because you
> have a dedicated wedge describing it would be a win in those situations.

I really don't forsee this happening. There will always be _a_ wedge=20
or a disk around that can be used as the target for partitioning tools.

Also, I expect we'll move towards GPT partitioning, and thus we'll move=20
away from our nested partitioning. So a lot of this hell will go away.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)