Date: Mon, 10 Jun 2002 20:28:10 +0200 From: Poul-Henning Kamp <phk@freebsd.org> To: arch@freebsd.org Subject: Statement of architectural direction: disklabel64 / GPT. Message-ID: <98152.1023733690@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98152.1023733690>