[CFC/CFT] large changes in the loader(8) code

[Kevin Oberman]

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