From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 13:15:23 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 E18AC106566B; Wed, 27 Jun 2012 13:15:23 +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 827DE8FC18; Wed, 27 Jun 2012 13:15: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 q5RDFM7R006272; Wed, 27 Jun 2012 09:15:22 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id q5RDFMsO006268; Wed, 27 Jun 2012 09:15: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 q5QLgo7R002613 for ; Tue, 26 Jun 2012 17:42:50 -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 q5QLgoxj018998 for ; Tue, 26 Jun 2012 17:42:50 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 083A8202C07; Tue, 26 Jun 2012 21:41:52 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B42211065713; Tue, 26 Jun 2012 21:41:47 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) 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 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by saltmine.radix.net id q5QLgo7R002613 Status: O X-Status: X-Keywords: X-UID: 156 X-Mailman-Approved-At: Wed, 27 Jun 2012 15:25:34 +0000 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:15:24 -0000 On Tue, Jun 26, 2012 at 2:23 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... > >> [...] 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. > > 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 fixed. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"