Statement of architectural direction: disklabel64 / GPT.

Robert Watson · *nix forums Guru Wannabe Joined: 22 Mar 2002 Posts: 218

Sounds like a good idea to me. Imagine, everyone using the same partition
scheme -- there must be some snag :-)

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories

On Mon, 10 Jun 2002, Poul-Henning Kamp wrote:

John Baldwin · *nix forums Guru Wannabe Joined: 27 Mar 2002 Posts: 278

On 10-Jun-2002 David Greenman-Lawrence wrote:

Poul-Henning Kamp · *nix forums Guru Joined: 21 Mar 2002 Posts: 436

In message <Pine.LNX.4.44.0206101635150.28471-100000@smtp.gnf.org>, Gordon Tetl
ow writes:

Marcel Moolenaar · *nix forums Guru Wannabe Joined: 03 Apr 2002 Posts: 120

On Mon, Jun 10, 2002 at 04:36:15PM -0700, Gordon Tetlow wrote:

Marcel Moolenaar · *nix forums Guru Wannabe Joined: 03 Apr 2002 Posts: 120

On Mon, Jun 10, 2002 at 08:28:10PM +0200, Poul-Henning Kamp wrote:
[snip]

Gordon Tetlow · *nix forums beginner Joined: 31 May 2002 Posts: 42

On Mon, 10 Jun 2002, Poul-Henning Kamp wrote:

Poul-Henning Kamp · *nix forums Guru Joined: 21 Mar 2002 Posts: 436

In message <20020610120956.L53004@nexus.root.com>, David Greenman-Lawrence writ
es:

David Greenman-Lawrence · *nix forums beginner Joined: 10 Jun 2002 Posts: 1

Poul-Henning Kamp · *nix forums Guru Joined: 21 Mar 2002 Posts: 436

The issue of 32->64 bit migration of struct disklabel has come up
now that daddr_t is 64 bit wide.

I have pondered the issue and researched what material I could find
and come to the conclusion that we should not make a 64bit version
of struct disklabel, but instead use the industry standard GPT format.

A 64bit BSD style disklabel would in best case be a {Free,Net,Open}BSD
thing, worst case just a FreeBSD thing. Either way I will argue
that it would be a private format.

Unless it can provide functionality otherwise not possible there
is no point in adding a new private format.

The GPT handles 16k partitions, 64 bit addressing, has decently
checksummed and redundant meta-data and space for per partition
meta-data.

I can't think of anything else we might need, so I have decided
not to make a 64bit disklabel format and instead use the GPT format.

This may result in us using the GPT format in ways not anticipated
by the standard (ie: embedded in a native partition on some odd-ball
platform) but that should not give any more or less trouble than
embedding a disklabel64 there.

We will need to support GPT for at least ia64 anyway, and I predict
that it will sneak into ia32 RSN as well, so this is actually less
work for us than doing a disklabel64.

Any objections ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

Google