I'm running UnRAID Plus 4.7 with 7 drives connected (6 array & 1 cache).  There are 5 drives running off my server's motherboard controller and 2 running off a PCIe Sil3132 based controller card.

 

Last night I heard some unusual rattling noises coming from the UnRAID box so fired up the web GUI to check the console.  One of the array drives was showing > 700 errors and the cache drive was in red status; both these drives are hanging off the PCIe controller.  I stopped the array and shut down the server but when it came back the cache drive was no longer showing in the device list and the errored array drive was showing as disabled.

 

My questions are:-

 

a) What can I do to check what caused the error (i.e. logs, etc)?

b) What are my chances of the controller having failed rather than the drives?

c) What steps should I take to remove the failed drives assuming I don't have a large enough drive to swap out the array drive?

 

I've had a look at the Wiki but I'm a little hesitant to follow the steps outlined there since I have 2 failed drives (albeit one is only the cache drive).  I'm fairly new to UnRAID so forgive my ignorance.  I have attached my Syslog in case it helps.

 

Edit: Have also attached the smart data report for the failed drive, short test only so far.  The short test passed so I'm now running the long test, will post log once complete.

 

Edited to mark as solved.

syslog-2012-06-11.txt

smart_report_sda.txt

Update:  Still waiting for the long test to complete but I can see some stats in the SMART status already which concern me :-

 

183 Runtime_Bad_Block = 39 (RAW value)

195 Hardware_ECC_Recovered = 1997 (RAW value)

200 Multi_Zone_Error_Rate = 1 (RAW value)

 

Update:  The drive made a loud squeaking noise for the last few hours (test around 70% completed).  Test is now 80% completed and the squaking noise has stopped.  It was like the one in this YouTube clip :-

 

 

The drive in the clip also happens to be a Samsung 1.5TB but I don't know if it's the same model that I have (mine's an internal drive).

Hmmm, the long test completed without error.  Previously reported SMART values are unchanged.  SMART report attached.

smart_report_sda_long.txt

Hmmm, the long test completed without error.  Previously reported SMART values are unchanged.  SMART report attached.

Looks like a good drive.  (although the squeaking might indicate some mechanical lubrication issue)

In Seagate's RMA process, one of the valid reasons for creating an RMA is "clicking noise". I've never returned a drive just because of a noise, but it looks as if it's possible to do.

Looks like a good drive.  (although the squeaking might indicate some mechanical lubrication issue)

 

Yet UnRAID disabled it, presumably for a write error?  Is that what the Multi Zone error stat relates to?  I have not fired it up yet today, too scared and have to go to work shortly; will look at it again when I get home.

 

In Seagate's RMA process, one of the valid reasons for creating an RMA is "clicking noise". I've never returned a drive just because of a noise, but it looks as if it's possible to do.

 

I first noticed a rattling noise coming from the drive, fairly soft too.  I didn't hear the squeaking till I ran the long test, might be a result of some action it was taking.

I've fired my UnRAID box up tonight  and had 3 drives in various states of being MIA.  On the UnMenu console the array was listed as "Error:Too many missing disks" and was stopped.  The states of the 3 drives in question were :-

 

DISK_NP_MISSING /dev/md4   Hitachi_HDS5C302_ML0220F30GNJ3D - Disk was OK yesterday but shown as spun down

DISK_DSBL_NP  /dev/md5   SAMSUNG_HD154UI_S1XWJDWZ316644 - This is the squeaking & clicking drive which passed both short and long tests in UnMenu

Not listed                WD Black 500 GB - This was my cache drive

 

After powering down and disconnecting and reconnecting all the sata cables at the drive end I have restarted and can now see all 3 drives again however /dev/md5 is still marked as disabled.  Is it just a matter of unassigning it and re-assigning it to re-enable it?  I'm still concerned about those smart attributes I posted earlier and the noisy drive (which strangely enough is silent at the moment).  I'm guessing it would be wise to remove it and test thoroughly with something like Seatools but can I just unassign it and leave it out or do I have to swap it out with another drive?  My array is nowhere near full so the other drives should have more than enough capacity.

 

Have attached current Syslog in case it helps with an answer 

syslog-2012-06-121.txt

You can just remove it. You won't have parity protection until you re-add it and reenable it, or add a new drive in its place.

So UnRAID won't re-adjust the remaining drives to take over for a missing one?

So UnRAID won't re-adjust the remaining drives to take over for a missing one?

 

No, but if you migrate the data off the array, and then back onto it, it'll be added to the existing drives.

 

No, but if you migrate the data off the array, and then back onto it, it'll be added to the existing drives.

 

It will be less painful to replace the drive  .  I actually think the existing drive may be OK and it was just a loose power cable, not 1 peep out of it durung the long test last night.  I'll still test it externally just to be sure which means swapping it out, might just have to use the WD EARS 2TB from my external case for that.

Can I just check I have the drive swap out process down correctly?

 

Assuming I want to swap out the disabled disk with a larger drive (i.e. my WD EARS 2TB) :-

 

1. Stop the array.

2. Unassign disabled disk.

3. Power down the server.

4. Replace disabled 1.5TB disk with 2TB disk ** all other array disks incl the parity disk are 2TBs **

5. Power up the unit.

6. Assign new disk to the array.

7. Start the array.

 

The drive being replaced is not the Parity disk so will I need to run parity and/or file system checks after replacing the drive?

depending on your version of unRAID, you may not need to perform step 6 (the disk might be recognized as a replacement automatically)

 

You may not (or may) need to check your file-systems for errors, but that has nothing to do with re-construction of a failed disk.

 

If the disk-being re-constructed had a file-system needing repair, the re-constructed disk will also have a file-system needing repair.  If the disk being re-constructed was not in need of repair, neither will the replacement.

 

After any re-construction it is best to perform a non-correcting parity check, just to make sure what you wrote to the new disk is readable.

 

depending on your version of unRAID, you may not need to perform step 6 (the disk might be recognized as a replacement automatically)

 

Sorry, thought I mentioned it earlier; I am running 4.7 Plus.

 

If the disk-being re-constructed had a file-system needing repair, the re-constructed disk will also have a file-system needing repair.  If the disk being re-constructed was not in need of repair, neither will the replacement.

 

Fair enough but how would I know?

 

After any re-construction it is best to perform a non-correcting parity check, just to make sure what you wrote to the new disk is readable.

 

I came across that in the Wiki, has to be run from command line or telnet IIRC.

If the disk-being re-constructed had a file-system needing repair, the re-constructed disk will also have a file-system needing repair.  If the disk being re-constructed was not in need of repair, neither will the replacement.

Fair enough but how would I know?

A drive that is able to be rebuilt using parity is also able to be accessed normally as a simulated drive.

 

In other words, with a single drive missing, you should still be able to see all the contents of that disk on the server. That simulated drive is what unRaid is going to write to the replacement, so if you can't read the simulated stuff, the rebuilt drive won't be readable either.

In other words, with a single drive missing, you should still be able to see all the contents of that disk on the server.

 

Does that mean that if I fired up my server now with the disk removed from the server and unassigned from the array I could still see it as "disk x" in the drive list via Window's Explorer?

The files and shares should appear unchanged with only one drive failure. The only indication of a single drive failure when accessing your network shares would be a slight decrease in speed, and all drives will stay spun up to simulate the failed drive. The only concrete indicator of a failed drive should be the webgui and syslog errors. If you have other symptoms, then you have more wrong than just a single failed array member.

The drive in question has passed both short and long tests in Seatools.  It failed the Seagate specific Short Drive Test but I'm not surprised since it's a Samsung HD154UI.  I haven't been able to find any Samsung specific testing software.

 

If I try and run any of the advanced tests I am warned about possible loss of data.  Will it matter considering UnRAID should have the data in simulated form?

 

I have checked the Smart info via CrystalDiskInfo and it still shows the single write error.  Considering this I really want to make sure if the drive is OK before putting it back into service, certainly I want to at least run a preclear on it.

OK so I fired up the server tonight to see if I could see the simulated contents of the failed disk.  There is a "disk5" share visible which contains some of my media directories (about 197gb in size); I'm assuming this was all that was on the missing disk.

 

I've decided to use my spare 2TB WD EARS drive to replace the disabled drive rather than re-use the suspect drive.  I'll be using the steps I listed earlier followed by a non-correcting parity check as per Joe L's advice earlier.

 

I'm planning on preclearing the replacement disk before assigning to the array.  I'm hoping UnRAID won't just grab the disk as a replacement for the missing disk but then Joe did mention it might get automatically assigned so I'm unsure if I'll get the chance.

 

Wish me luck!

Well my preclear and rebuild to the new disk has finally completed.  I want to run a non-correcting Parity Check now but can't seem to find the relevant section in the Wiki now.  Can someone please guide me in running this from the command line?

 

NVM, found it :-

 

"In the same way, after replacing a data disk, it is recommended that a non-correcting parity check be run. This is only available on the command line after logging in via telnet or on the system console as root. To perform that test, log in and type:

 

/root/mdcmd check NOCORRECT"

 

It's ticking away nicely now.

 

Edited: Spelling

 

OK so the Parity Check has completed with 0 errors found.  Is that all I need to do to check the rebuild went OK?

Yes. Run pre-clear on the suspect disk and if it passes then it becomes the new spare.

I can't run a preclear on the suspect disk, I have no slots left in my server.  It's a HP Microserver which already has 7 drives shoehorned into it.

 

I've tested the suspect disk outside of the server and it comes up fine, I think the original problem was caused by a loose cable.  I'll be re-using that disk elsewhere since it's now too small to be used in the restored array.

 

Looks like I can mark this case as solved now.