On Wed, Jun 06, 2007 at 07:24:52AM -0000, De Zeurkous wrote:
> And why not just introduce a new, limitless, copy-on-write disklabel? We
> have something that fits perfectly in our system, and I see no reason to

"Fits perfectly" is where some folks would disagree.

Let's back up for a minute.  One problem that we've had ever since
the earliest days on an i386-based system is the dichotomy between
the native partitioning method (call it what you will) and the BSD
partitioning method (disklabel).  On traditional BSD systems, there
was just the disklabel.  The PC needed a lower-level format, and
BSD needed to coexist with it.  So disklabelling became a two-step
process: prepare the native label, and prepare the BSD label.  And
people want to be able to share BSD with other operating systems--
Linux, Windows, DOS, OS/2, other BSD installs, whatever.  And so
we need to be able to treat the BSD portion of the disk separately
from the whole disk as well as be able to access the whole disk at
times, so the choice was made to have two 'raw disk' partitions, one
meaning 'whole disk' and one meaning 'BSD portion of disk.'  That
has been a small thorn in our side for quite a while.  It's a bit
confusing to both people and code, and it makes for one less usable
partition.  Now we're also up to the point where logical volumes
(if not quite yet individual spindles) can exceed the sizes that we
can represent in the traditional disklabels.

These are orthogonal issues.  Wedges help to solve some of them, but
there are also some other reasons that wedges make sense, such as
the fact that the old Apple partition scheme doesn't map very well
to disklabels.  We've hacked around it for years, but wedges map
much better to that system.  And we'd like to have a more consistent
view of the devices between ports.  And then there's the question of
how many partitions does that disklabel/port support?  8?  16?  It's
a "flag day" for a port if/when it changes, without a device filesystem,
and it's a bit of a pain to deal with making devices properly in a
machine-independent fashion.

For just going to wider representations of the partition size &
offset, sure, it's not too bad to define a disklabel64 or whatever--
the technical issues surrounding that are relatively easily hacked
around.  But GPT is an existing format that maps well to wedges,
which we want for other reasons.  It also allows for other systems
and tools to interoperate with the disks--not an issue for many
installs, but an issue for some, and more of an issue for USB or
firewire (or eSATA) disks that may well be shared between different
kinds of systems for backups or sharing data or whatever.  So why
have yet another way of looking at the disks?  It adds to the
complexity of low-level code, resulting in more code to compile
(size) and test / debug.

-allen

-- 
Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  briggs@ninthwonder.com