Skip site navigation (1)Skip section navigation (2)
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> wrot=
e:
> 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 sect=
ors,
>> > when it finds the "GEOM::" signature in the last sector. PMBR code als=
o
>> > tries to do the same:
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 common/gpt.c
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 i386/pmbr/pmbr.s
>>
>> GPT really wants the backup header at the last LBA. =C2=A0I know you can=
 set it,
>> but I've interpreted that as a way to see if the primary header is corre=
ct 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 G=
EOM
>> provider) will not work properly with partition editors for other OS's. =
=C2=A0I'm
>> hesitant to encourage the use of this as I do think putting GPT inside o=
f 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 fixe=
d.
--=20
R. Kevin Oberman, Network Engineer
E-mail: kob6558@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1vBSPjeP6HzuH4ityRhguGhi-b9Nd=YRfyAtfNZaNSC7A>