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>