From owner-freebsd-geom@FreeBSD.ORG Thu Apr 22 21:10:13 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48FE5106566C; Thu, 22 Apr 2010 21:10:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 46D148FC08; Thu, 22 Apr 2010 21:10:11 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA15153; Fri, 23 Apr 2010 00:10:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O53et-0008XM-91; Fri, 23 Apr 2010 00:10:03 +0300 Message-ID: <4BD0BB2A.1090503@icyb.net.ua> Date: Fri, 23 Apr 2010 00:10:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Marcel Moolenaar References: <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> In-Reply-To: <75798832-C041-4796-8C10-5BE61FB7583A@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , Marcel Moolenaar , freebsd-geom@freebsd.org Subject: Re: OCE and GPT X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 21:10:13 -0000 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