"secondary GPT table is corrupt or invalid" issue again

[Luchesar V. ILIEV]

On 01/09/2011 00:37, Zeus V Panchenko wrote:
> Andrey V. Elsukov (bu7cher at yandex.ru) [11.01.08 13:55] wrote:
>>
>> FreeBSD 8.2 has implemented support of recovering GPT. You can try to
>> boot from livefs image or just update your system and use
>> 'gpart recover'. But i strongly suggest to read related paragraph
>> in manual page before. Backup is recommended of course.
>>
> 
> what if i detach one hdd from mirror, than recover the one in mirror
> and attach the first one again, will it be right way?
> 

Hi Zeus,

Just my two cents. If I understood correctly from your first mail,
you've set up the gmirror on /dev/ada{1,2}p1; that is, you're not
mirroring the whole disk, but just the (single) partition on it.

gmirror(8) stores its metadata in the last sector of the provider, and
since in your case that's the partition itself, I can't see how it could
have overwritten the secondary GPT. I was wondering if your problem
could be related to the ahci(4) driver? I think I've seen reports of
problems with data integrity; considering that this infrastructure is
not yet as mature as the old ata(4)-based one, this doesn't seem totally
impossible with certain devices. Then again, I'd find it a bit strange
to have only the secondary GPT get corrupt and nothing else if the
problem had indeed been in the ahci driver...

Speaking of that (and not related directly to your question), you might
find it more convenient to use GPT partition labels in the future. For
instance, in your example you could label the partitions...

# gpart modify -i 1 -l teradisk0 ada1
# gpart modify -i 1 -l teradisk1 ada2

...and then could create the mirror using the labels...

# gmirror label -v -h -b load gm0 gpt/teradisk0
# gmirror insert -v -h -p 1 gm0 gpt/teradisk1

Using -h is important here, as otherwise gmirror will "forget" the
labels. I'd like to draw your attention to the -p parameter as well.
AFAIK it's not good to have the components with equal priority. Priority
determines not only the preferred disk for the "prefer" algorithm, but,
more importantly, the disk which is considered "master" when a resync is
needed. This gets especially critical if you insert a blank component to
a mirror which already holds data. gmirror might do the right thing, but
probably not exactly for the right reasons. To summarize, I'd recommend
that you always keep the disk you'd like to be "master" with priority
"0" (which is considered highest) and all the rest in the mirror with
lower (probably diminishing) priorities.

Concerning the backup thing: what you described sounds reasonable to me,
but with one very important thing to remember: the priorities again!
If something goes wrong with the GPT recovery, be sure to set the
priorities of the components the right way: the disk you consider
healthy should be set with priority "0" and the other one with "1". You
can change the priority of a component with e.g...

# gmirror configure -v -p 1 gm0 ada1p1

...and you've already noticed that you can set the priority of the
inserted components as well.

Of course, if you keep important data on that mirror, it might be still
best to simply replicate it somewhere else, and take no risks.

One last thing that you might consider: the sysutils/gdisk port. It's
quite a capable program for maintaining GPT formatted disks, which could
prove helpful in certain cases (e.g. with the protective MBRs).

Good luck, and please let us know if you find what caused your problems.

Cheers,
Luchesar

P.S. Please keep in mind that I might be wrong in some (or even all) of
my assumptions and suggestions. I do have some experience with GPT and
gmirror, but it's definitely far away from being extensive.