Subject: Re: Work-in-progress "wedges" implementation
To: Chapman Flack <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 09/30/2004 17:54:30
Content-Type: text/plain; charset=us-ascii
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----