OCE and GPT

[Andriy Gapon]

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