Date: Tue, 11 Jun 2002 18:08:08 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Poul-Henning Kamp <phk@freebsd.org> Cc: arch@freebsd.org Subject: Re: Statement of architectural direction: disklabel64 / GPT. Message-ID: <Pine.NEB.3.96L.1020611180741.14838G-100000@fledge.watson.org> In-Reply-To: <98152.1023733690@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>
> 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
>
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?Pine.NEB.3.96L.1020611180741.14838G-100000>