On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek <p...@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: kob6...@gmail.com _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"