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>