From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:40:39 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 D0075106564A for ; Fri, 17 Feb 2012 02:40:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 70D978FC1B for ; Fri, 17 Feb 2012 02:40:39 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1H2eZR7048475; Thu, 16 Feb 2012 19:40:35 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1H2eZmQ048472; Thu, 16 Feb 2012 19:40:35 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 16 Feb 2012 19:40:35 -0700 (MST) From: Warren Block To: Jeremy Chadwick In-Reply-To: <20120217021019.GA61420@icarus.home.lan> Message-ID: References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <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> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 16 Feb 2012 19:40:36 -0700 (MST) Cc: freebsd-stable@freebsd.org, Mike Andrews , 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 02:40:39 -0000 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. Short-form: GPT tables are at the absolute start and end of the physical disk. GEOM metadata is relative, at the end of the logical device, not necessarily the end of the physical device. >> On the other hand, GEOM stuff works inside GPT partitions. And if >> that's not acceptable, MBR partitions will be around for a long >> time. > > MBR partitions don't scale past 2TB. Arguing that use of MBR is an > acceptable workaround is the equivalent to burying one's head in the > sand. Let's try to accept the future, not feign ignorance. I wasn't recommending it. If putting GEOM data inside GPT partitions isn't acceptable (but why not?), there's the alternative of not using any partitioning at all. Create the GEOM device on the bare drive using the full space. Of course it won't boot...