Date: Wed, 21 Apr 2010 16:56:24 +0400 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Andriy Gapon <avg@icyb.net.ua> Cc: Lister <lister@kawashti.org>, Marcel Moolenaar <marcel@FreeBSD.org>, freebsd-geom@FreeBSD.org Subject: Re: OCE and GPT Message-ID: <4BCEF5F8.6090102@yandex.ru> In-Reply-To: <4BCEEF06.8010203@icyb.net.ua> References: <B814515407B5445092FD63116EA3DA6B@neo> <4BCEE9E2.6010007@yandex.ru> <4BCEEC66.1080804@yandex.ru> <4BCEEF06.8010203@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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? -- WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BCEF5F8.6090102>