OCE and GPT

Andriy Gapon avg at icyb.net.ua
Thu Apr 22 21:10:13 UTC 2010


on 21/04/2010 20:59 Marcel Moolenaar said the following:
> On Apr 21, 2010, at 10:48 AM, Andrey V. Elsukov wrote:
> 
>> 21.04.10, 16:59, Andriy Gapon:
>>
>>>> providers withing scheme. But with GPT we have problem, after
>>>> booting with bigger media size the second partition table will
>>>> be lost. And GPT will be broken.
>>> Why?
>>> Do we have it hardcoded where to look for the secondary GPT?
>> Yes. Current implementation does search for second GPT table only at last LBA.
>> And it violates with UEFI 2.3 specification.
> 
> No, it's ACCORDING to the specification:
> 
> UEFI version 2.3, page 99 (paragraph 5.3.1):
> "Two GPT Header structures are stored on the device: the primary and the
>  backup. The primary GPT Header must be located in LBA 1 (i.e., the second
>  logical block), and the backup GPT Header must be located in the last LBA
>  of the device."

This makes total sense for the 'steady state', otherwise how the secondary table
would be discovered when the primary table is lost.

Actually, now I think that it doesn't matter much where we look for the
secondary table when we already have valid primary table - as long as we don't
make it a fatal error when the secondary table is invalid.
(But I still think that checking AlternateLBA is more correct, because otherwise
why would it exist at all?)

I guess that a reason for having the secondary table is to increase chances of
survival, of getting to the data: primary table is OK, then fine; primary is
bad, but secondary is OK, then still fine.  (But there should be diagnostics to
alert a user, of course).
What we have in FreeBSD right now actually decreases chances of survival - if
either table is not OK, then we disregard the other table and just fail.  A user
has to do a recovery using disk editor.  No help from the OS.

I think that what Andrey is doing takes us in the correct direction.

-- 
Andriy Gapon


More information about the freebsd-geom mailing list