Skip site navigation (1)Skip section navigation (2)
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>