Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Oct 2006 14:46:59 -0600
From:      "Rick C. Petty" <rick-freebsd@kiwi-computer.com>
To:        freebsd-geom@freebsd.org
Subject:   Re: burnt again by gmirror
Message-ID:  <20061031204659.GA56766@keira.kiwi-computer.com>
In-Reply-To: <4547AD9B.5050503@centtech.com>
References:  <20061031195442.GA55478@keira.kiwi-computer.com> <4547AD9B.5050503@centtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 31, 2006 at 02:10:03PM -0600, Eric Anderson wrote:

> You probably need to do a gmirror forget, then a gmirror remove (on
> ad8), then re-insert it.

The forget seemed to fix it.  FYI:

# gmirror remove gm0 ad8
No such provider: ad8.

I'm not sure if that step was even necessary.  At least now both ad4 and   
ad8 are listed and are of the same size.  I was worried gmirror would try  
to allocate its metadata on ad8 twice.  I don't know why I thought that,   
because gmirror would treat the ad8 as a provider and overwrite any 
previous metadata when doing a "gmirror insert".

> gmirror probably kicked it out because of errors?

I guess that's what my question was really trying to get at.  What caused  
the error, what was the error, and why did gmirror both not recognize ad8  
and also think there was a missing disk.  I guess if it was expecting a    
specific ID and ad8 no longer had that ID (it got wiped for some odd 
reason?) it would behave as such.  That explains the last question.  The   
first two are hard to diagnose w/o dmesg.  :(

Still, I'm curious why/how ad8's metadata could have been clobbered.
gmirror is the only one who would write to it, the filesystem is mounted
from gm0* -- kinda scary.  I guess the lesson here is to use simple gmirror
configurations in case the metadata gets clobbered.

-- Rick C. Petty



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061031204659.GA56766>