Date: Fri, 23 Apr 2010 00:10:02 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Marcel Moolenaar <xcllnt@mac.com> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, Marcel Moolenaar <marcel@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: OCE and GPT Message-ID: <4BD0BB2A.1090503@icyb.net.ua> In-Reply-To: <75798832-C041-4796-8C10-5BE61FB7583A@mac.com> References: <B814515407B5445092FD63116EA3DA6B@neo> <4BCEE9E2.6010007@yandex.ru> <4BCEEC66.1080804@yandex.ru> <4BCEEF06.8010203@icyb.net.ua> <4BCEF5F8.6090102@yandex.ru> <4BCF04C7.1050701@icyb.net.ua> <50691271872096@web136.yandex.ru> <75798832-C041-4796-8C10-5BE61FB7583A@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD0BB2A.1090503>