From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 05:37:49 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 BFFC6106566C for ; Fri, 17 Feb 2012 05:37:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7307E8FC19 for ; Fri, 17 Feb 2012 05:37:48 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2984025vcm.13 for ; Thu, 16 Feb 2012 21:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MNYoQm3/54jJEYMTTH2r+WFbsYnlfydDou0SYYkN3Ds=; b=Y834JBLoCkuuBs96F2pWEueRvcbUNiPK6mLNr/XjZYL1zp6soWFhqFF299EniNym8Q G/F3lOHNVceg4OFAyzfiW7fxsMvE0ixqt2XUHqk8yBwMAlOEw1Im8UK/4ysIHjjLpKRg K1g9uUMlGGwk7kqr0hvUoMQwmTGiE78+4YlbA= MIME-Version: 1.0 Received: by 10.52.27.70 with SMTP id r6mr2524459vdg.41.1329457068419; Thu, 16 Feb 2012 21:37:48 -0800 (PST) Received: by 10.220.192.135 with HTTP; Thu, 16 Feb 2012 21:37:48 -0800 (PST) In-Reply-To: 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> Date: Thu, 16 Feb 2012 21:37:48 -0800 Message-ID: From: Freddie Cash To: Warren Block Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Andrews , freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick 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 05:37:49 -0000 On Thu, Feb 16, 2012 at 6:40 PM, 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. =C2=A0F= or >> version 1.0, I'm not sure. =C2=A0For version 1.1 it looks like the metad= ata >> 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. =C2=A0GEOM classes don't lie= , they > accurately represent the space. =C2=A0The space provided by a gmirror is = one > block less than the actual space occupied, to allow for the metadata bloc= k > at the end. =C2=A0The 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. =C2=A0We= ll, the > last block of it, anyway. > > But create the GEOM device inside a GPT partition that spans the drive, a= nd > things are fine. =C2=A0The 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. =C2=A0GEOM metadata is relative, at the end of the logical device, = not > necessarily the end of the physical device. Seems to me that we need a GEOM-aware loader that can "taste" the GEOM metadata on a disk *before* the GPT is read, such that the "first and last physical block of the disk" becomes "the first and last physical block of the GEOM provider". Perhaps by storing the GEOM class metadata in the first and last blocks of the provider. Then you just start reading the start of the disk, notice a gmirror metadata block, setup the gmirror, notice a gstripe metadata block, setup the gstripe, notice a GPT metadata block, load the GPT partitions, etc No idea just how feasible this would be, though. --=20 Freddie Cash fjwcash@gmail.com