Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jun 2012 23:23:08 +0200
From:      Pawel Jakub Dawidek <pjd@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Andriy Gapon <avg@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: [CFC/CFT] large changes in the loader(8) code
Message-ID:  <20120626212308.GE1399@garage.freebsd.pl>
In-Reply-To: <201206261337.11741.jhb@freebsd.org>
References:  <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--jKBxcB1XkHIR0Eqt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 secto=
rs,
> > 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
>=20
> GPT really wants the backup header at the last LBA.  I know you can set i=
t,=20
> but I've interpreted that as a way to see if the primary header is correc=
t or=20
> 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 GE=
OM=20
> provider) will not work properly with partition editors for other OS's.  =
I'm=20
> hesitant to encourage the use of this as I do think putting GPT inside of=
 a=20
> 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.

--=20
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl

--jKBxcB1XkHIR0Eqt
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAk/qKDsACgkQForvXbEpPzTuQQCg3kjmILCtG1x3GK+/ZmSRXGyr
eQ0Anjd+C2ocL3sr5lOVZv+NlQ3+4s2Q
=A8qf
-----END PGP SIGNATURE-----

--jKBxcB1XkHIR0Eqt--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120626212308.GE1399>