From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 04:23:32 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 0D2C710656EE for ; Fri, 17 Feb 2012 04:23:32 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD65A8FC14 for ; Fri, 17 Feb 2012 04:23:30 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H4LktH099723; Fri, 17 Feb 2012 13:21:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H4LfZs034408; Fri, 17 Feb 2012 13:21:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Feb 2012 13:20:21 +0900 (JST) Message-Id: <20120217.132021.880997830536801810.hrs@allbsd.org> To: freebsd@jdc.parodius.com From: Hiroki Sato In-Reply-To: <20120217030806.GA62601@icarus.home.lan> References: <20120217021019.GA61420@icarus.home.lan> <20120217030806.GA62601@icarus.home.lan> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb_17_13_20_21_2012_576)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 17 Feb 2012 13:22:01 +0900 (JST) X-Spam-Status: No, score=-103.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_VERTICALLINE, QENCPTR1, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: wblock@wonkity.com, freebsd-stable@FreeBSD.org, mandrews@bit0.com, 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 04:23:32 -0000 ----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeremy Chadwick wrote in <20120217030806.GA62601@icarus.home.lan>: fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: fr> > Sorry, I may be misunderstanding your point. GEOM classes don't fr> > lie, they accurately represent the space. The space provided by a fr> > gmirror is one block less than the actual space occupied, to allow fr> > for the metadata block at the end. The problem is that GPT puts fr> > backup partition tables at the end of the physical (not logical) fr> > device. Create a GEOM device on that drive, and the GEOM metadata fr> > overwrites the backup GPT partition table. Well, the last block of fr> > it, anyway. fr> > fr> > But create the GEOM device inside a GPT partition that spans the fr> > drive, and things are fine. The GPT backup tables are safely fr> > outside the GEOM metadata, which is safely outside of the data. fr> fr> I wasn't aware you could do that. I was only aware that it was the fr> other way around. That (my) misconception seems to also be relayed fr> by others such as Miroslav who said: fr> fr> >>GPT doesn't play nice with GEOM classes which store their metadata fr> >>on last sector. For example, you can't use gmirror of a whole drives fr> >>and use GPT on top of this mirror. (and gmirror is not the only one) fr> fr> So if I read this correctly, it means that the erroneous behaviour is fr> the result of someone doing things "in the wrong order" (for lack of fr> better terminology). Well, does GPT really depend on the absolute last block? The header has fields for both the first and the last LBAs and they do not have to be matched with the physical capacity. Creating a gmirror first, and then creating a GPT on it does not work? I do not think it is true, and I suspect a description on gmirror recommending kern.geom.debugflags=17 in the handbook is the source of the problem. The partition layout in my mind is the following: (0) (last) |PMBR|GPT primary| .... |GPT secondary|gmirror meta| |<------------------------------------------------->| ada0 |<------------------------------------>| | mirror/gm0 | |<----->| | mirror/gm0p{1,2,...} and the following commands will create an example of this configuration: # mdconfig -a -t vnode -s100m md0 # mdconfig -a -t vnode -s100m md1 # gmirror label gm0 /dev/md0 /dev/md1 # gmirror dump /dev/md0 | grep size mediasize: 104857088 sectorsize: 512 provsize: 104857600 # gpart create -s gpt mirror/gm0 # gpart add -t freebsd-ufs mirror/gm0 mirror/gm0p1 added => 34 204732 mirror/gm0 GPT (100M) 34 204732 1 freebsd-ufs (100M) # echo "(34 + 204732) * 512" | bc 104840192 The size of GPT header + partition entries is 33 sectors. So, # echo "(34 + 204732) * 512 + 33 * 512" | bc 104857088 is the size which the GPT recognizes. This matches the size of mirror/gm0, not /dev/md0. This means the gmirror metadata is located just after it. I think this should work in most cases for mirroring the whole disk. Certainly the gpart reports "[CORRUPT]" if the underlying device capacity does not match with the GPT header. For example, deactivating mirror/gm0 above will show the following: # gpart show => 34 204732 mirror/gm0 GPT (100M) 34 204732 1 freebsd-ufs (100M) # gmirror stop gm0 # gpart show => 34 204732 md1 GPT (100M) [CORRUPT] 34 204732 1 freebsd-ufs (100M) => 34 204732 md0 GPT (100M) [CORRUPT] 34 204732 1 freebsd-ufs (100M) # gpart recover md0 md0 recovered # gpart show => 34 204732 md1 GPT (100M) [CORRUPT] 34 204732 1 freebsd-ufs (100M) => 34 204733 md0 GPT (100M) 34 204732 1 freebsd-ufs (100M) 204766 1 - free - (512B) We can see the gpart recover extends the size to the last sector where gmirror metadata was placed and clears the "[CORRUPT]" status as expected. So, some early boot stages which do not recognize mirror/gm0 see the corrupted GPT. However, I think they will simply follow the information in the GPT header. -- Hiroki ----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk891YUACgkQTyzT2CeTzy2TWgCfSaDckdcDPNR/+R0nJWA1Eu5r gtoAoNOw0gLhPM/eFwOCiABY7v88ZvmH =TDXP -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)----