Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jun 2012 10:37:11 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Doug Rabson <dfr@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>, freebsd-hackers <freebsd-hackers@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org>, freebsd-current <freebsd-current@FreeBSD.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>
Subject:   Re: [CFC/CFT] large changes in the loader(8) code
Message-ID:  <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net>
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

On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>=20
> GPT really wants the backup header at the last LBA.  I know you can =
set it,=20
> but I've interpreted that as a way to see if the primary header is =
correct or=20
> not.  It seems to me that GPT tables created in this fashion (inside a =
GEOM=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.

Agreed.

While it is a nice trick to use the last sector for meta data, it does
create 2 problems. 1 is mentioned above. The second is that when there's
different metadata in the first *and* the last sector, you can't decide
which is to take precedence without also looking at the other and know
how to interpret it. We have not solved this second problem at all.  We
do get reports about the problems though. At best we're handwaving or
kluging.

I think it's unwise to depend on FreeBSD-specific extensions or features
in industry-standard partitioning schemes and as such make the use of
"foreign" tools hard if not impossible.

A much more flexible approach is to support out-of-band configuration
data. This allows us to mirror GPT disks without having to become non-
standard as it removes the need to use the last sector for meta-data.
The ability to construct GEOM hierarchies unambiguously is very
important and our current approach has proven to not deliver on that.
This is actually impacting existing FreeBSD consumers already, like
Juniper. So, se should not go deeper into this rabbit hole. We should
finally solve this problem for real...

--=20
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?468988EA-AC50-451D-ACE1-17B58E0CAF67>