Date: Tue, 30 Nov 2004 12:15:22 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Chris Hedley <cbh-freebsd-current@groups.chrishedley.com> Cc: Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: GEOM: gpt partitions on a gmirror array possible? Message-ID: <20041130201522.GA92745@ns1.xcllnt.net> In-Reply-To: <20041130153044.E20313@teapot.cbhnet> References: <20041127193532.X15946@teapot.cbhnet> <20041129133825.GL7232@darkness.comp.waw.pl> <20041129183511.GA84117@ns1.xcllnt.net> <20041130153044.E20313@teapot.cbhnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 30, 2004 at 03:37:52PM +0000, Chris Hedley wrote:
> >
> >I guess a change like geom_mbr.c:1.57 is in order, or a more to-the-
> >point test for rejecting GPT on MBR or GPT on GPT.
>
> Any suggestions before I start butchering the file in question?
Removal of the following should do it without causing problems:
if (gp->rank != 2 && insist == 0)
break;
In fact, this is the fix I'm considering. The strength of GEOM is
that you can create arbitrary layering and nesting and imposing
limitations seems counter productive. There may be an advantage to
allow GPT on MBR or GPT on GPT even if it's disallowed under EFI.
We already allow the use of GPT outside the context of EFI...
BTW: I will then probably also enforce that if there's a MBR sector
front of the GPT table, it must be a PMBR. Use of GPT on a
boot disk is possible by putting a GPT table inside an MBR
slice. In a sense, I trade width for depth :-)
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041130201522.GA92745>