Date: Mon, 27 Jan 2003 09:46:31 +0100 From: phk@freebsd.org To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Nate Lawson <nate@root.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sbin/disklabel disklabel.c Message-ID: <20076.1043657191@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 27 Jan 2003 00:35:36 PST." <20030127083536.GA2644@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030127083536.GA2644@dhcp01.pn.xcllnt.net>, Marcel Moolenaar write s: For BSD the problem is that the disklabel is inside the partition(s) and that there is a boatload of historical interfaces and conventions. For MBR it is "only" the historical interfaces and conventions which get in the way. As far as I know, GPT does not repeat BSD's mistake of putting the meta-data inside the partitions, so nothing prevents you from creating a (actually two: one for each copy) partitions which map to the area of the disk where the metadata is. You can even do this with the normal slice + hotspot mechanism. And you don't have any historical brain-damage to protect, so you can do it right from the start :-) -- 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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20076.1043657191>