Date: Tue, 30 Nov 2004 15:37:52 +0000 (GMT) From: Chris Hedley <cbh-freebsd-current@groups.chrishedley.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: GEOM: gpt partitions on a gmirror array possible? Message-ID: <20041130153044.E20313@teapot.cbhnet> In-Reply-To: <20041129183511.GA84117@ns1.xcllnt.net> References: <20041127193532.X15946@teapot.cbhnet> <20041129133825.GL7232@darkness.comp.waw.pl> <20041129183511.GA84117@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Nov 2004, Marcel Moolenaar wrote: > On Mon, Nov 29, 2004 at 02:38:25PM +0100, Pawel Jakub Dawidek wrote: >> >> It is because GEOM_GPT class only allow to create GPT labels on rank#1 >> providers (i.e. disks). I'm not sure why we have this hack, maybe marcel@ >> knows something more (cc'ed). > > It's there, because it was there for the MBR class when I used that > class as a blueprint for implementing GPT support. Since GPT is not > allowed within an MBR slice, or within a GPT partition (no nesting), > not to mention all the non-native partitioning schemes that GEOM > supports, that test made sure we only tasted GPT partitions on the > one kind of providers that existed besides slicers: disks. > > 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. Thanks for the quick responses, guys. While the great and good are considering it, I may in the meantime throw caution to the wind and see if I can make some appropriately ad hoc changes to my own system. Any suggestions before I start butchering the file in question? Maybe since I no longer need more than 7 partitions per logical volume I should go back to using bsdlabel for the time being, although that feels too much like taking the easy way out. :) Chris.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041130153044.E20313>