From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 13:14:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41BDA1065674; Wed, 27 Jun 2012 13:14:24 +0000 (UTC) (envelope-from root@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id E14DC8FC12; Wed, 27 Jun 2012 13:14:23 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5RDEM7R005804; Wed, 27 Jun 2012 09:14:22 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id q5RDEMPw005803; Wed, 27 Jun 2012 09:14:22 -0400 (EDT) Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5QLRJ7R000428 for ; Tue, 26 Jun 2012 17:27:19 -0400 (EDT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail1.radix.net (8.13.4/8.13.4) with ESMTP id q5QLRJU0016728 for ; Tue, 26 Jun 2012 17:27:19 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 41635160A8B; Tue, 26 Jun 2012 21:25:42 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 60E081065815; Tue, 26 Jun 2012 21:25:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E421065672; Tue, 26 Jun 2012 21:25:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A65138FC0C; Tue, 26 Jun 2012 21:25:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4254BB84; Tue, 26 Jun 2012 23:25:11 +0200 (CEST) Date: Tue, 26 Jun 2012 23:23:08 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Status: O X-Status: X-Keywords: X-UID: 98 Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:14:24 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: > > 4. The gptboot now searches the backup GPT header in the previous secto= rs, > > when it finds the "GEOM::" signature in the last sector. PMBR code also > > tries to do the same: > > common/gpt.c > > i386/pmbr/pmbr.s >=20 > GPT really wants the backup header at the last LBA. I know you can set i= t,=20 > but I've interpreted that as a way to see if the primary header is correc= t or=20 > not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... > [...] It seems to me that GPT tables created in this fashion (inside a GE= OM=20 > provider) will not work properly with partition editors for other OS's. = I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside of= a=20 > gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. In other words, IMHO, our problem is that FreeBSD's boot code doesn't recognize/support gmirror's metadata. What Andrey is proposing is to recognize the metadata and act accordingly - in case of a gmirror we simply need to skip it. In the future we will have the same problem with graid - until we add support for it to the boot code, we won't be able to boot from it. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qKDsACgkQForvXbEpPzTuQQCg3kjmILCtG1x3GK+/ZmSRXGyr eQ0Anjd+C2ocL3sr5lOVZv+NlQ3+4s2Q =A8qf -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt--