Haai,

On Wed, June 6, 2007 17:16, Bill Stouder-Studenmund wrote:
> On Wed, Jun 06, 2007 at 07:24:52AM -0000, De Zeurkous wrote:
>> Haai,
>>
>> On Wed, June 6, 2007 04:31, Bill Stouder-Studenmund wrote:
>> > MBR, Apple partitoin maps, and disklabel labels all use 32-bit nubmers
>> to
>> > count sectors. Thus they have issues with disks larger than 2 TiB
>> (2^32
>> > blocks). You can play games with block sizes, but that will get you
>> only
>> > so far. And it will be very non-portable.
>>
>> 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
>> change it. Funky mapping and such can all be done on a higher level.
>
> Did you not read what I said?
>
> How is a structure with 32-bit block numbers going to describe a disk with
> more than 2^32 blocks?

Did you not read what _I_ said? That's right, I was talking about a /new/,
improved type of disklabel. It spanned at least a fifth of this entire
discussion.

>
>>[snip]
>
> No. It means for large disks, ones over 2 TiB.

Again, a new copy-on-write-based disklabel will eliminate that limitation.

>
>>[snip]
>
> The NetBSD project's experience, as I have seen on this list, in my
> personal experience, and in other discussions, does not agree that the BSD
> disklabel "fits perfectly [in] our system." It is what we have, but it's a
> mess.

I have already indicated that I see the rust spots, as well. Hoewever,
that doesn't mean there aren't better solutions than GPT out there, like
redesigning our own disklabel.

>
> It also is not the only partitioning scheme we use.

That's nice, actually -- it gives sysadmins a choice.

>
> We have had discussions regarding this for over a decade. The end result
> has been that we want to go with wedges, so that we separate kernel
> partition handling from the on-disk formatting. Further, we have decided
> to go with GPT as the long-term on-disk format where permitting. We aren't
> going to stop reading disklabels nor make folks repartition disks nor
> force this where the boot system (sun3 or mac68k for instance) won't
> handle it.

My exact point -- or, rather, the right half of it -- is that wedges
should provide a compatibility interface, not define disk layout. The left
half of it is that we should still provide decent physical formats. And,
again as I indicated, I think GPT isn't the magic it seems to have been
accepted as.

>
>>[snip]
>
> Overhead? Yes, GPT uses bigger structures than MBR or disklabel. But are
> we really worried about it? In the kernel, it'll resolve into a wedge with
> a block offset and a block length.

Yes, we /are/ worried about it, or at least we should be. The pointer and
GUID sizes provided by GPT won't last forever. Again, we need a
copy-on-write format, with limits intialized upon creation of the label.

>
> As for device addressing, check into wedges.

Since GPT is supposed to be cross-platform (and will remain so for a while
until it gets too tempting for certain involved commercial parties to make
proprietary modifications) I was adressing both this and the previous
issues as a generic OS problems; some OSes haven't resolved them yet.

>
>>[snip]
>
> Why should we totally roll our own on something when GPT already exists,
> and does a lot of things we need and things we want?

Because there are limits to 'worse is better'.

>
>>[snip]
>
> Uhm, I've done it before. Been using one OS and reclaimed a partition I'd
> originally set aside for another OS.

The issue concerned reclaiming partitions from/in foreign-formatted
slices, not different native partitions.

>
> One problem this discussion has is that you are being very dismissive of
> GPT. While you don't have to like it, you aren't bothering to try and
> figure out why people like it.

That's not true -- I have investigated the issue thoroughly from a number
of viewpoints. The conclusion I came with is that some people are happy
enough already having a carrot instead of a stick, no matter if it's
rotten or how bitter it tastes. In some cases, it could be laced with
cyanide and there would still be people not caring.

> We like it as it meets a number of our
> needs. If you never know these needs, I don't see how you're going to
> propose a solution that will solve our needs better.

Perhaps that's because I don't believe 'worse is better' is the final
word, especially when a solution is available that's perhaps a little more
complex in the short term, but far more productive in the long term.

Baai,

De Zeurkous
------------

Friggin' Machines!

>
> Take care,
>
> Bill
>