From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 21:41:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E931D106566B; Tue, 26 Jun 2012 21:41:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id BA8328FC12; Tue, 26 Jun 2012 21:41:37 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so319193wib.13 for ; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EJULjC4LRx83lPPCAVyN1VZ3wmJAs3iDoqR8+Yb2QUU=; b=M64njnVyOA8TMFrQjLP5RSGyNbAFlr1E6y55xU6WpPNkheIbSTGbYfrx4lLX6OtlnT UTqV/gDSZDlA+tV5cfd8FVfcpl3xOjGoXx4JLNZY1rqmf8K5NTNNnyPlzSVe1iJoCDdX J19pxSuc6Tppja0y6rS/FK+skGMuDOe5jHe7H/3Qpb+wzjvQimLXkPFzqT6EnnxMBFAt eSyV458Xhb5Pcl6tY7MA4L9/Q+wfeCArayRTTUBRQVeQR0xK7bnbec6oxOuTh9ODkHQ1 PahIOqpKneBN0lGhrD/24IhkMZD/aGcG65AbpsPFQqTfido6uSu3tkR5EMJETl2l6Sh/ CYWw== MIME-Version: 1.0 Received: by 10.180.79.166 with SMTP id k6mr36239762wix.8.1340746891280; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> Date: Tue, 26 Jun 2012 14:41:31 -0700 Message-ID: From: Kevin Oberman To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:41:39 -0000 On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek wrot= e: > 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 sect= ors, >> > when it finds the "GEOM::" signature in the last sector. PMBR code als= o >> > tries to do the same: >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 common/gpt.c >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 i386/pmbr/pmbr.s >> >> GPT really wants the backup header at the last LBA. =C2=A0I know you can= set it, >> but I've interpreted that as a way to see if the primary header is corre= ct 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... > >> [...] It seems to me that GPT tables created in this fashion (inside a G= EOM >> provider) will not work properly with partition editors for other OS's. = =C2=A0I'm >> hesitant to encourage the use of this as I do think putting GPT inside o= f 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. > > 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. Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixe= d. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com