[patch] resize and recover support for GPART GPT scheme

[Andriy Gapon]

on 22/04/2010 14:35 Andrey V. Elsukov said the following:
> On 21.04.2010 17:59, Andriy Gapon wrote:
>> 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
> 
> I implemented 'recover' verb. I changed detection algoritm in GPT scheme.
> Now when primary GPT header is valid reading of second header will be
> done from alternateLBA offset (which read from GPT header).
> When primary header is invalid reading of second header will be from the
> last medium's LBA.
> 
> And now the following scenario works:
> ====================================================================
> # dd if=/dev/zero of=./d.img bs=1m count=100
> 100+0 records in
> 100+0 records out
> 104857600 bytes transferred in 2.895854 secs (36209560 bytes/sec)
> # mdconfig -f d.img
> md0
> # gpart create -s gpt md0
> md0 created
> # gpart add -t freebsd-zfs md0
> md0p1 added
> # gpart show md0
> =>    34  204733  md0  GPT  (100M)
>       34  204733    1  freebsd-zfs  (100M)
> 
> # mdconfig -du 0
> # dd if=/dev/zero of=./d.img bs=1m count=50 seek=100
> 50+0 records in
> 50+0 records out
> 52428800 bytes transferred in 1.175911 secs (44585689 bytes/sec)
> # ls -lh d.img
> -rw-r--r--  1 root  wheel   150M 22 апр 14:56 d.img
> # mdconfig -f d.img
> md0
> # dmesg | tail -2
> GEOM: md0: the secondary GPT table is corrupt or invalid.
> GEOM: md0: using the primary only -- recovery suggested.
> # gpart show md0
> =>    34  204733  md0  GPT  (150M)
>       34  204733    1  freebsd-zfs  (100M)
> 
> # gpart recover md0
> md0 recovered
> # gpart show md0
> =>    34  307133  md0  GPT  (150M)
>       34  204733    1  freebsd-zfs  (100M)
>   204767  102400       - free -  (50M)
> 
> # gpart resize -i 1 md0
> md0p1 resized
> # gpart show md0
> =>    34  307133  md0  GPT  (150M)
>       34  307133    1  freebsd-zfs  (150M)
> ====================================================================
> 
> There are several things that can be do where i need suggestions.
> 1. What code should do when user doing `gpart recover` for scheme
> that doesn't need recovering?

Do you mean the schemes that do not support recovery (like MBR)?  The answer is
obvious.
If you mean GPT in OK state, when both copies are correct, then the code could
just return success and, perhaps, some diagnostic message.

> 2. Probably there are needed some checks before changing metadata in
> g_part_gpt_recover method.
> 
> So, patch attached and comments are welcome.

Without deep analysis the patch looks good.
Just to be sure - it handles the case when primary table is corrupt but the
secondary (at the end of media) is OK?
I will try to fully review your patch a little bit later.

Thanks a lot!
-- 
Andriy Gapon