Date: Mon, 27 Jan 2003 01:50:04 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: phk@freebsd.org 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: <20030127095004.GA2876@dhcp01.pn.xcllnt.net> In-Reply-To: <20076.1043657191@critter.freebsd.dk> References: <20030127083536.GA2644@dhcp01.pn.xcllnt.net> <20076.1043657191@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 27, 2003 at 09:46:31AM +0100, phk@freebsd.org wrote: > 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. I don't see how this changes the fact that we're still just reading and writing. If ioctls really make a difference than I don't have a problem with the creation of ioctls in these cases. Those will be the compatibility interfaces. > 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. The specification continues by dictating that the MBR that preceeds the GPT has to be a protective MBR and thus has a predefined partition that covers the whole diski (or the maximum possible with MBR). Clearly, one cannot create overlapping partitions, which means that the MBR cannot also be used to fake partitions for the meta-data. Ergo: the kludge does not work. > And you don't have any historical brain-damage to protect, so you > can do it right from the start :-) Well, kludging with fake partitions and ioctls to do regular I/O isn't quite what I would call "doing it right from the start". I think a "historical brain-damage to be" bucket would be more fitting :-) Seriously: I think too much effort is going into avoiding dealing with the root cause by creating flawed work-arounds and making all sorts of assumptions that will bite you in the ass one way or the other. I realize that fixing the root cause may be more work, but at least that would be a one time thing... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030127095004.GA2876>