On Sat, 21 Nov 2009, Ted Unangst wrote: > On Fri, Nov 20, 2009 at 2:08 PM, Jeff Ross <jr...@openvistas.net> wrote: >> I failed a drive (*NOT* with a nail gun, though, I just removed it ;-) and >> bioctl correctly showed the drive as failed and the raid running as >> degraded. I re-inserted the same drive but I was unable to find any magic >> bioctl -R that would kick off a rebuild. >> >> I shutdown that server, removed the failed drive and inserted it into >> another identical SuperMicro. System booted, noted an unclean shutdown, ran >> fsck and was at login in short order. >> >> So, just for fun I shutdown the second server, took its drive and >> reinstalled in the second slot of the first again and fired it up. As the >> system booted the second drive's light lit solid on so I suspected a behind >> the scenes rebuild was going on. When I got logged in bioctl -v mpi0 shows >> both drives online, and the raid status is Rebuild. > > I have no idea what magic your raid controller has, but unless it > understands filesystems, this is really asking for trouble. You have > two similar but slightly different filesystem images. You are going > to "merge" them?
No, I don't think that's the way it is supposed to work. > > I assume/hope the the raid card just picked one drive as the winner > and is going to wipe the other, because that's the only way this could > work. Maybe I've always misunderstood hardware raid controllers but I thought that's the way they are supposed to work, especially with raid1. One drive in the set fails, the controller notes that, and if a hot spare is available it begins rebuilding the array using the hot spare, replacing the failed drive. In my scenario, in a 1U server with 2 enclosures I do not have a hot spare online but I still have a good drive and a failed drive. Replacing the failed drive, even with the exact same hard disk, has to result in copying the good drive to the new drive, right? Jeff
