From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 12:22:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EC3E10657A9; Wed, 27 Jun 2012 12:22:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D58018FC19; Wed, 27 Jun 2012 12:22:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA784B9A0; Wed, 27 Jun 2012 08:22:51 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 27 Jun 2012 08:22:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> MIME-Version: 1.0 Message-Id: <201206270822.25672.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:51 -0400 (EDT) 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 X-Mailman-Version: 2.1.5 Precedence: list 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 12:22:53 -0000 On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote: > 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 sectors, > > > 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 > > > > GPT really wants the backup header at the last LBA. I know you can set it, > > but I've interpreted that as a way to see if the primary header is correct or > > 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... Right, which is why this fails. > > [...] It seems to me that GPT tables created in this fashion (inside a GEOM > > provider) will not work properly with partition editors for other OS's. I'm > > hesitant to encourage the use of this as I do think putting GPT inside of a > > 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. Hardware RAIDs hide the metadata from the disk that the BIOS (and disk editors) see. Thus, putting a GPT on a hardware RAID volume works fine as the logical volume is always seen by all OS's consistently. The same is even true of the "software" RAID that graid supports since the metadata is defined by the vendor and thus the logical volume is always seen other OS's consistently. My approach has been to only use gmirror with MBR so far, though I realize that doesn't work above 2TB (until recently one had to have a hardware RAID to get above 2TB anyway which made this last a moot point). I won't object to patch our tools to handle this, but I think it is a really bad idea that users will have a hard way to recover from when they are bitten by it. -- John Baldwin