Here's the situation...

 

A few weeks ago, one my my Seagate 3TB disks ( Disk 8 ) started reporting a lot of read errors.  Having run across this before, and done some research, I knew it wasn't an uncommon problem for these particular drives to have, especially when used in an unraid array.  I had a spare drive (unfortunately, it was the exact same type of 3TB seagate), so I popped it in and ran one cycle of the preclear_disk script on it.  Unfortunately, I has also recently noticed that I was having difficulty writing to the array, saying I had no write permissions, which led me to believe at least one other drive was being mounted in read-only mode due to file system errors, so I ran reiserfsck on the other drives while preclearing the new drive.  Sure enough, my disk 7 (which was a Hitachi 3TB drive) reported that I needed to rebuilt the FS tree... so, not thinking about the fact that I would soon need to do a data rebuild from parity, I went ahead and started the process. 

 

As soon as I saw the first tree correction being written to the disk, I realized what I had done - basically I'd invalidated my parity information.  Sure enough, once the preclear of the new disk finished and I started a data rebuild, I got a "remaining time" estimate of a little over 60 days.  Normally that's pretty standard during the first few minutes of a data rebuild, but typically it drops down to 20 hours or less once it's been going a while.  Not this time.  In addition, I heard frequent double beeps during the process, which I believe was the "parity error" beep pattern.

 

So, I stopped the rebuild.  Since the old, failed drive hadn't actually died yet, I figured that I could skip the whole data rebuild process and just hook that drive up to another PC (or just not assign it to the array on my unraid box) and then copy all of its contents over to the new Disk 8, tell unraid to trust the array, do a parity check, and all would be fine.  Am I on the right track?  If not, is there any alternative?  If so, what exact steps do I need to take to trust the array in the New unraid 5.0, as the wiki page seems to indicate that the old process won't work anymore.

Did you do the check on the /dev/mdX device or on the /dev/sdX1 device?

 

Is there still a problem with another drive or not?

 

You won't get parity errors during a rebuild. unRAID doesn't know there are parity errors during a drive rebuild. unRAID is simply using the parity and the other drives to rebuild onto the replacement drive. If there are parity errors, then the new drive gets messed up data each place there is an parity error.

I did it on /dev/sdh1, I believe.  As far as the beeping goes, that's just what the IT guy at work suggested, but now that I think about it I believe the RAID controller would only beep with parity errors if it were using the hardware RAID built into the card, so I'm not really sure what the beeping was.  It was always just two concurrent beeps from the computer speaker, and there might be as little as 5 minutes between two sets of beeps, or up to 45 minutes, which is why I initially thought he might be right.  Other than parity errors, I have no idea what could be causing the beeping - I've had this many drives in my system for a long time, and done at least 3 data rebuilds in the past, and never had any beeping occur in the past.

The instructions say to use the /dev/mdX device for file system checks so you did do it wrong.

 

Pull the SMART reports on the other drives and try to find another problem drive. The beeping could be the controller having difficulty reading from a drive.

 

FYI, you can copy the data to the new drive but that won't make the parity correct. You broke parity when you did the file system check. you could clone or copy the disk and basically set a new config and assign the drives and start the array to build parity again.

 

I wouldn't do anything else though until you figure out what the problem is. At least one of the drives is having issues for the rebuild to have failed.

Sure enough, you're right.  I guess I'll just copy the data from the old drive to the new one and rebuild the parity from scratch.  None of the other disks show any problems in their SMART reports - the only time any beeping has ever occurred was during the data rebuild.  Weird.

Something was wrong. There must have been a disk reading or writing problem or possibly a failing disk to cause the rebuild to go very slow and not work right.