Date: Fri, 29 Jun 2012 11:47:34 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: pjd@FreeBSD.org 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 Message-ID: <20120629.114734.957117006298853448.hrs@allbsd.org> In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> References: <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pawel Jakub Dawidek <pjd@freebsd.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120629.114734.957117006298853448.hrs>