Date: Fri, 24 Apr 2009 22:12:47 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-questions@freebsd.org Subject: Re: Unexpected gmirror behavior: Is this a bug? Message-ID: <gst6gn$b05$1@ger.gmane.org> In-Reply-To: <gst5g4$6ss$1@ger.gmane.org> References: <32442523.2901240597865043.JavaMail.HALO$@halo> <22026228.2921240597983327.JavaMail.HALO$@halo> <gst5g4$6ss$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4363BD2D54ABB3222B3DF4BE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Peter Steele wrote: >> We had a somewhat startling scenario occur with gmirror. We have syste= ms with four drives ad4, ad6, ad8, and ad10, with the OS setup on a mirro= red slice across all four drives. The ad4 drive failed at one point, due = to a simple bad connection in its drive bay. While it was offline, the sy= stem was continued to be used for a while and new data was added to the m= irrored file system.=20 >> >> We eventually took the box down to deal with ad4, and tried simply pul= ling and reinserting the drive. On reboot we saw that the BIOS detected t= he drive, so that was good. However, when FreeBSD got to the point of sta= rting up the GEOM driver, instead of reinserting ad4 into the more curren= t mirror consisting of ad6/ad8/ad10 and resyncing it with that data, the = GEOM driver assumed ad4 was the "good" mirror and ended up resyncing ad6/= ad8/ad10 with the data from ad4, causing the new files we had added to th= ose drives to be lost.=20 >> >> This only happens with ad4. If ad6 for example goes offline in the sam= e way, when it is reinserted it does not become the dominant drive and re= sync its data with the other drives. Rather its data is overwritten with = the data from the 3 member mirror, as you'd expect.=20 >> >> So, clearly ad4, the first disk, is treated specially. The question is= this a bug or a feature? Is there anyway to prevent this behavior? This = would be a disastrous thing to happen in the field on one of our customer= systems.=20 >=20 > This definitely looks like a bug. Try asking again on the freebsd-geom@= > list. Provide output of "gmirror list". >=20 > From what you said it looks like you did the procedure safely - you > turned off the server, then pulled the drive and reinserted it, then > turned it on again, right? Sorry, that was a useless response - what I said should be a no-op. So, your steps were: 1. ad4, ad6, ad8 and ad10 in a 4-way mirror 2. ad4 fails. At this point did you do a "gmirror list"? I.e. did gmirror detect it failing? If I read it correctly, the GenID field should have been increased in this case. 3. The system continues to be used 4. You power it down, take out and reinsert ad4 5. On boot, ad4 is detected, inserted in the mirror but as a "known good" copy, not a stale one. Correct? What version of FreeBSD are you using? --------------enig4363BD2D54ABB3222B3DF4BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknyHUUACgkQldnAQVacBcjZQgCg2fOOSbe0D/CeAk8E6HX7har5 /+EAoMoDBqWwHRk5zKHMFZ/DPsLzGtlh =Ijmf -----END PGP SIGNATURE----- --------------enig4363BD2D54ABB3222B3DF4BE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gst6gn$b05$1>