From owner-freebsd-geom@FreeBSD.ORG Wed Apr 21 17:48:20 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 11D89106566C; Wed, 21 Apr 2010 17:48:20 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id AFC568FC17; Wed, 21 Apr 2010 17:48:19 +0000 (UTC) Received: from web136.yandex.ru (web136.yandex.ru [95.108.130.34]) by forward11.mail.yandex.net (Yandex) with ESMTP id D6B883ED0655; Wed, 21 Apr 2010 21:48:17 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1271872097; bh=Hl52msHd5VYFvZ7M0qm9Rjy0D950OhFVLHv9HN4q+Ak=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=kZiwgy5hDfJyPZdszGjy7vagGf4nMmt6/nfM8t7mnbgZid3resg97DB8txyfQWt9w iU8mQfHV1aXvmRMdrjTYyjRJGph1J+NIcJ1Rn9ufttlVqcSFnA3BjBBBVLtgesZAOn CbDkZHocWjKrgER9Yj2u+najyJeh+R2LWjdIvHNc= Received: from localhost (localhost.localdomain [127.0.0.1]) by web136.yandex.ru (Yandex) with ESMTP id D369D24F807E; Wed, 21 Apr 2010 21:48:17 +0400 (MSD) X-Yandex-Spam: 1 X-Yandex-Front: web136.yandex.ru X-Yandex-TimeMark: 1271872097 Received: from [77.72.138.63] ([77.72.138.63]) by mail.yandex.ru with HTTP; Wed, 21 Apr 2010 21:48:15 +0400 From: Andrey V. Elsukov To: Andriy Gapon In-Reply-To: <4BCF04C7.1050701@icyb.net.ua> References: <4BCEE9E2.6010007@yandex.ru> <4BCEEC66.1080804@yandex.ru> <4BCEEF06.8010203@icyb.net.ua> <4BCEF5F8.6090102@yandex.ru> <4BCF04C7.1050701@icyb.net.ua> MIME-Version: 1.0 Message-Id: <50691271872096@web136.yandex.ru> Date: Wed, 21 Apr 2010 21:48:16 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Lister , Marcel Moolenaar , freebsd-geom@freebsd.org Subject: Re: 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: Wed, 21 Apr 2010 17:48:20 -0000 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. > I also think that this recovery mechanism is needed. > In short: > recover - re-create secondary table based on primary table Also there can be situation when primary table is corrupted, but secondary isn't. > reinit - relocate secondary table to a new position and update offsets in both > tables accordingly What should reinit do when nothing was changed? > > it was before? Should we reject this way of recovering and allow recovering > > only for the same size or bigger media size? > > I think that we could allow smaller media size _provided_ that lost space doesn't > overlap with any partitions found in primary table. Otherwise it's a data loss > scenario and a user should be left to deal with it. IMHO, of course. Current implementation rejects table where 'LastUsableLBA' is greather than last medium's LBA. This behavior also doesn't described in UEFI spec. =) I think if we will have recover and reinit verbs implemented we can change some algorithms of table detection. -- WBR, Andrey V. Elsukov