From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 03:08:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A9D106566C for ; Fri, 17 Feb 2012 03:08:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id DBBFA8FC08 for ; Fri, 17 Feb 2012 03:08:08 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id ar1e1i0051ZXKqc57r89Ph; Fri, 17 Feb 2012 03:08:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.westchester.pa.mail.comcast.net with comcast id ar871i01p1t3BNj3hr88cq; Fri, 17 Feb 2012 03:08:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7708D102C1E; Thu, 16 Feb 2012 19:08:06 -0800 (PST) Date: Thu, 16 Feb 2012 19:08:06 -0800 From: Jeremy Chadwick To: Warren Block Message-ID: <20120217030806.GA62601@icarus.home.lan> References: <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mike Andrews , freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 03:08:09 -0000 On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: > On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > > >On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote: > > (...Linux mdadm) > >So for version 0.90 of their metadata format, you lose drive capacity by > >about 64-128KBytes, given that the space is needed for metadata. For > >version 1.0, I'm not sure. For version 1.1 it looks like the metadata > >can be stored at the beginning. > > > >So overall, this sounds to me like the equivalent of if GEOM was to > >"lie" about the actual capacities of the devices when using classes that > >require use of metadata (gmirror, etc.). > > Sorry, I may be misunderstanding your point. GEOM classes don't > lie, they accurately represent the space. The space provided by a > gmirror is one block less than the actual space occupied, to allow > for the metadata block at the end. The problem is that GPT puts > backup partition tables at the end of the physical (not logical) > device. Create a GEOM device on that drive, and the GEOM metadata > overwrites the backup GPT partition table. Well, the last block of > it, anyway. > > But create the GEOM device inside a GPT partition that spans the > drive, and things are fine. The GPT backup tables are safely > outside the GEOM metadata, which is safely outside of the data. I wasn't aware you could do that. I was only aware that it was the other way around. That (my) misconception seems to also be relayed by others such as Miroslav who said: >>GPT doesn't play nice with GEOM classes which store their metadata >>on last sector. For example, you can't use gmirror of a whole drives >>and use GPT on top of this mirror. (and gmirror is not the only one) So if I read this correctly, it means that the erroneous behaviour is the result of someone doing things "in the wrong order" (for lack of better terminology). However, with the methodology you describe (GEOM device inside a GPT partition), are our bootloader bits (BTX, etc.) smart enough to figure this out and thus be able to boot/load kernel/so forth from such a device? (Note that this question is different from your later mention of creating the GEOM device on the bare drive with no partitioning, in which case yep, won't be bootable). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |