Date: Mon, 27 Jan 2003 10:53:55 +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: <21120.1043661235@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 27 Jan 2003 01:50:04 PST." <20030127095004.GA2876@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030127095004.GA2876@dhcp01.pn.xcllnt.net>, Marcel Moolenaar write s: >> 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. > >Yes, GPT does prevent us from doing that because the GPT header >contains the first and last LBA of user storage that is managed >by the GPT and the GPT itself is not user storage and hence >cannot be included in the range. Since all partitions have to be >defined between the first and last LBA, it follows immediately >that GPT does not allow covering the GPT meta-data with partitions. I didn't mean you should create GPT partitions to cover them, that would be repeating the BSD label mistake. I simply meant that the geom_gpt.c class should create two providers which correspond to the applicable ranges of the consumer. Those two would show up in /dev as "ad0.gpt0" and "ad0.gpt1" or whatever you decide to call them, and you can open/read/write them as much as you like: no need for ioctls. -- 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?21120.1043661235>