Date: Tue, 26 Jun 2012 14:41:31 -0700 From: Kevin Oberman <kob6558@gmail.com> To: Pawel Jakub Dawidek <pjd@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: <CAN6yY1vBSPjeP6HzuH4ityRhguGhi-b9Nd=YRfyAtfNZaNSC7A@mail.gmail.com> In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote: > 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 sectors, >> > 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 >> >> GPT really wants the backup header at the last LBA. I know you can set it, >> but I've interpreted that as a way to see if the primary header is correct or >> 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 GEOM >> provider) will not work properly with partition editors for other OS's. I'm >> hesitant to encourage the use of this as I do think putting GPT inside of a >> 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. Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixed. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1vBSPjeP6HzuH4ityRhguGhi-b9Nd=YRfyAtfNZaNSC7A>