From owner-freebsd-current@FreeBSD.ORG Mon Nov 29 18:35:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D3C916A4CE; Mon, 29 Nov 2004 18:35:15 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A864443D6A; Mon, 29 Nov 2004 18:35:14 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id iATIZDiO084238; Mon, 29 Nov 2004 10:35:14 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.1/8.13.1/Submit) id iATIZBnZ084237; Mon, 29 Nov 2004 10:35:11 -0800 (PST) (envelope-from marcel) Date: Mon, 29 Nov 2004 10:35:11 -0800 From: Marcel Moolenaar To: Pawel Jakub Dawidek Message-ID: <20041129183511.GA84117@ns1.xcllnt.net> References: <20041127193532.X15946@teapot.cbhnet> <20041129133825.GL7232@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041129133825.GL7232@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: Chris Hedley Subject: Re: GEOM: gpt partitions on a gmirror array possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 18:35:15 -0000 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. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net