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>