Date: Sun, 09 Jan 2011 16:02:16 +0200 From: "Luchesar V. ILIEV" <luchesar.iliev@gmail.com> To: zeus@ibs.dn.ua Cc: freebsd-geom@freebsd.org Subject: Re: "secondary GPT table is corrupt or invalid" issue again Message-ID: <4D29BFE8.8050407@gmail.com> In-Reply-To: <20110109092709.GC66627@relay.ibs.dn.ua> References: <20110104170611.GA67159@relay.ibs.dn.ua> <4D28509D.607@yandex.ru> <20110108223747.GA66627@relay.ibs.dn.ua> <4D28FB15.9090907@gmail.com> <20110109092709.GC66627@relay.ibs.dn.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/09/2011 11:27, Zeus V Panchenko wrote:
> Hi Luchesar,
>
> thank you for reply,
>>
>> 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.
>>
> really the history was this:
> i configured first drive as GPT (whole dedicated drive), newfs-ed it
> and filled with data
>
> after what i created mirror on it but not on entire disk /dev/ada0 (not on it's
> single partition /dev/ada0p1) and i believe it was the cause of corruption
>
> latter i found maillist explanation of the mistake and reconfigured
> the mirror to use partitions instead of entire disk ... so, this way
> the corruption appeared as i can judge now
>
Ah, that really makes sense now. Actually, a good warning too, as you
wouldn't expect such problems with MBR partitioned disks.
>> 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
>
> no, i do not believe it is ahci(4) related issue since no other
> simpthomes were observed (smart data shows no problems too)
>
>>
>> # 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,
>
> mmm ... what will happend when master dies? will gmirror understand
> that 0 priority disk now the one remaining alive? or i have to handle
> that manually? to reassign 0 to the survived disk and to assign next
> index to the new disk?
>
Good point. Actually, the "master" is not necessarily the provider with
priority "0", but the one with the highest (that is, the lowest number)
one, which is still alive. So, if you have for example a three-way
mirror with provider priorities 0, 1 and 2, when the master dies, the
second disk (with priority "1") will become master.
Yes, I suppose you should always be careful to set the correct
priorities when you insert new providers to the mirror. Concerning the
"dead master", keep in mind as well that it won't simply disappear from
the configuration -- you'll have to issue "gmirror forget" first,
otherwise it will keep showing up as missing.
But I'm not really sure what would happen, if you return the master,
with its metadata intact, but with all the other information on it gone.
Obviously, if gmirror decides that it should resync all other disks to
it, that would be a disaster. Perhaps someone more knowledgeable could
shed more light on this matter. Again, though, setting the priorities
manually should prevent such cases, as you'd always make sure to have a
"healthy" disk being the "master".
While "ordinary" mirrors generally provide very good reliability, I find
ZFS's ability to also provide data integrity critical. So, today I'm
using gmirror exclusively for swap, and in rare occasions for geli(8)
encrypted devices that also need redundancy. And managing zpool(1M)-s is
also very convenient. Even today I'm going to totally rearrange the disk
setup on my desktop; had I not been using ZFS, I wouldn't even consider
it until next reinstall. :)
Cheers,
Luchesar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D29BFE8.8050407>