Peter Steele wrote: > We had a somewhat startling scenario occur with gmirror. We have systems with > four drives ad4, ad6, ad8, and ad10, with the OS setup on a mirrored 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 system was > continued to be used for a while and new data was added to the mirrored file > system. > > We eventually took the box down to deal with ad4, and tried simply pulling > and reinserting the drive. On reboot we saw that the BIOS detected the drive, > so that was good. However, when FreeBSD got to the point of starting up the > GEOM driver, instead of reinserting ad4 into the more current 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 those drives to be > lost. > > This only happens with ad4. If ad6 for example goes offline in the same way, > when it is reinserted it does not become the dominant drive and resync its > data with the other drives. Rather its data is overwritten with the data from > the 3 member mirror, as you'd expect. > > 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.
This definitely looks like a bug. Try asking again on the freebsd-geom@ list. Provide output of "gmirror list". 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?
Description: OpenPGP digital signature