From owner-freebsd-geom@FreeBSD.ORG Wed Apr 21 13:59:46 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 6AD221065670; Wed, 21 Apr 2010 13:59:46 +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 7695F8FC0A; Wed, 21 Apr 2010 13:59:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA05010; Wed, 21 Apr 2010 16:59:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BCF04C7.1050701@icyb.net.ua> Date: Wed, 21 Apr 2010 16:59:35 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4BCEE9E2.6010007@yandex.ru> <4BCEEC66.1080804@yandex.ru> <4BCEEF06.8010203@icyb.net.ua> <4BCEF5F8.6090102@yandex.ru> In-Reply-To: <4BCEF5F8.6090102@yandex.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Lister , 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: Wed, 21 Apr 2010 13:59:46 -0000 on 21/04/2010 15:56 Andrey V. Elsukov said the following: > On 21.04.2010 16:26, Andriy Gapon wrote: >> will your patch take care of moving the second copy of GPT towards >> (new) disk end >> if disk size is increased? > > Current implementation of resize feature is targeted to resize > 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? Or do we enforce that it is at the very end of disk? My understanding is that GPT partition table header contains positions of both primary and secondary GPT (fields at offsets 24 and 32). I think that we should use that and growing disk would not cause any problem. GPT scheme would cover only a portion of disk, but that should be OK as a temporary state. Then, we could have some additional command like 'reinit' that would relocate the secondary table to the new end of disk and update recorded positions to new values. > I think first of it should be recovered. > And there are some plans about implementing this feature. > After that partitions within scheme can be resized with my patch. I also think that this recovery mechanism is needed. In short: recover - re-create secondary table based on primary table reinit - relocate secondary table to a new position and update offsets in both tables accordingly > Recovering of GPT will write secondary table and also should fix internal > information about media size. And there can be several ways (if we think > about > generic implementation). What should we do when media size will be > smaller that > 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. -- Andriy Gapon