Subject: Re: Work-in-progress "wedges" implementation
To: NetBSD tech-kern <tech-kern@NetBSD.org>
From: Chapman Flack <flack@cerias.purdue.edu>
List: tech-kern
Date: 09/30/2004 18:56:05
Jason Thorpe wrote:
> On Sep 29, 2004, at 5:42 PM, Daniel Carosone wrote:
> 
> > 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.
> 
> It does?  Even in the traditional BSD disklabel scheme, only the file 
> system that resides in the partition that "overlaps" the label area is 
> going to "have access to" that disklabel.

Wasn't Daniel's point that this filesystem is written on a partition that
contains disklabel data describing (among other things) other partitions?

>From a different message:

> Consider, for example, a partitioning scheme that stores multiple 
> copies of its information for redundancy purposes.  GPT is one such 
> format.

How is such a thing accommodated now, if it is?  What is done by code
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.

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 sysadmin
has to bend over backward to get the information.  We've probably all known
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.

-Chap