From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 03:06:00 2012 Return-Path: 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 C9658106566B; Fri, 29 Jun 2012 03:05:59 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 0149C8FC12; Fri, 29 Jun 2012 03:05:58 +0000 (UTC) Received: from alph.allbsd.org (p4242-ipbf1504funabasi.chiba.ocn.ne.jp [118.7.211.242]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q5T35WTi080211; Fri, 29 Jun 2012 12:05:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q5T35SaH061314; Fri, 29 Jun 2012 12:05:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 29 Jun 2012 11:47:34 +0900 (JST) Message-Id: <20120629.114734.957117006298853448.hrs@allbsd.org> To: pjd@FreeBSD.org From: Hiroki Sato In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> References: <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_29_11_47_34_2012_987)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 29 Jun 2012 12:05:44 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-Mailman-Approved-At: Fri, 29 Jun 2012 03:36:02 +0000 Cc: dfr@FreeBSD.org, marcel@FreeBSD.org, xi@borderworlds.dk, freebsd-hackers@FreeBSD.org, avg@FreeBSD.org, marcel@xcllnt.net, se@FreeBSD.org, bu7cher@yandex.ru, Alexander@Leidinger.net, freebsd-current@FreeBSD.org 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: Fri, 29 Jun 2012 03:06:00 -0000 ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pawel Jakub Dawidek wrote in <20120628230725.GB1438@garage.freebsd.pl>: pj> PS. We are discussing two totally different things here: pj> 1. Is placing GPT on anything but raw disk violates the spec? I can pj> agree that it does and I'm happy with gpart(8) growing a warning. I agree that there is a sort of violation, but in practice most of implementations which use GPT can recognize the backup header as long as the primary one is not corrupted by using the alternative LBA field. One thing we have to consider is what happens when the primary header becomes broken. In that case and if a GEOM metadata is placed at the end of the raw disk, GPT will be lost and it cannot recover by non-GEOM-aware software including BIOS and other OS. Also, even for FreeBSD it causes a boot failure. The modification which ae@ proposes mitigates this case. Of course, maybe BIOS or EFI will not recognize the corrupted header because the backup header is not located at the end. In that case all of the partitions are not recognized and the FreeBSD does not boot. This is the trade-off when we use GPT in a logical volume provided by GEOM. In short, the risk is that backup header does not work as a backup when the primary is broken. I agree that putting a warning about that is good and enough. Whether this risk is acceptable or not depends on the sysadmin. Also, we can describe the pros and cons in detail in a section of the handbook because I and wblock@ are working on updating it. pj> 2. How to do software mirroring. Besides trying really hard I'm not sure pj> what alternative are you proposing. Could you be more specific and pj> describe how gmirror should be implemented in your opinion? I do not think this topic is related to ae@'s change and this should be discussed in a separate thread. His change aims to support a non-standard GPT header location in a quite limited situation, not actively promote such a configuration. The issue of GPT+GEOM is not limited to gmirror. Just putting GEOM::LABEL metadata causes the same issue. -- Hiroki ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/tF0YACgkQTyzT2CeTzy1kOgCfVfIyJA3wP4V+tAeNSOb/fD9D jx4An3Buxn6SA3rVPDkMuYTZNgVU7QZj =R0+R -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)----