--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 06, 2007 at 07:24:52AM -0000, De Zeurkous wrote:
> Haai,
>=20
> 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.
>=20
> 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=
=20
more than 2^32 blocks?

> > As far as I can tell, Windows and Mac OS have standardized on GPT for s=
uch
> > disks, and I think Linux also uses only GPT for them. Thus GPT is the
> > choice for such disks.
>=20
> I hope that last sentence was intended to mean 'for disks which, by some
> strange logic glitch, use GPT and need to multi-boot'...

No. It means for large disks, ones over 2 TiB.

> > So we need GPT regardless of what else we may do.
>=20
> It would certainly improve compatibility, but I don't see why we should
> use it ourselves. The BSD disklabel fits in perfectly with our system and
> I see no reason at all not to improve it instead of switching to a
> generic, bloated solution on this low level.

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=
=20
mess.

It also is not the only partitioning scheme we use.

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. And we're lagging on the tools.

> > Given that we need GPT, it makes sense to use it as a way to clean up a
> > number of other issues. GPT, especially with wedges, is not limited to a
> > fixed number of partitions. It's been designed to not have a number of
> > issues we've faced with our current labeling options.
>=20
> The real problems, like overhead and OS device addressing, still remain.

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

As for device addressing, check into wedges.

> > GPT maps also have the advantage that all OSs can understand the
> > partitions. Yes, not much other than NetBSD will understand our file
> > system, but Windows and Mac OS and Linux will know where our partitions
> > start and end.
>=20
> Windoze will /not ever/ interpret most types of disklabels, and we all
> know the reason. As for the Unices, Lunix can do it already. Not sure
> about Darwin, though. Then again, our code is wide open and anyone can
> copy it.

Why should we totally roll our own on something when GPT already exists,=20
and does a lot of things we need and things we want?

> > So if you end up needing to reclaim a partition while
> > running another OS, you can.
>=20
> The chances of that happening on any serious system are to the point of
> non-existence.

Uhm, I've done it before. Been using one OS and reclaimed a partition I'd=
=20
originally set aside for another OS.

One problem this discussion has is that you are being very dismissive of=20
GPT. While you don't have to like it, you aren't bothering to try and=20
figure out why people like it. We like it as it meets a number of our=20
needs. If you never know these needs, I don't see how you're going to=20
propose a solution that will solve our needs better.

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGZuvdWz+3JHUci9cRAsUwAJ91rDrIlQlGSMfaa7WxFfD0DdkWdgCfXR5/
TIfSWJ/BfebhaZi22w+ibbU=
=HO1k
-----END PGP SIGNATURE-----

--pf9I7BMVVzbSWLtt--