Recently I had some internet issues which required a long powerdown of my router. When I powered backup I couldnt contact my unraid server so had to hit the power button on the server initiating an unclean powerdown.

 

When I powered it back up it started doing a parity check as expected. It quickly found 8 Parity Sync errors before i could even load the web interface. It didnt discover any more Parity Sync errors after that though. However when it did finish the parity check it came up telling me there were 66 "Errors" on drive 9. 

 

I havent had time to do anything else with the server since this happened as i've been out of town but there have been no writes to the array since the errors occured for fear of losing/corrupting any data.

 

Attached is a zip of my syslog (which has a heap of DHCP stuff at the bottom so you will need to scroll up to the date where the errors occured - 6th June) as well as a screen shot of the web interface showing the errors.

 

Also I noted that Disc 8 took approximately 50% more reads to do the parity check compared to all the other discs - 9.5 million-ish reads on disc 8 versus 6 million-ish on all the others of the same size. Is this normal or signs of something wrong with that drive as well as Disc 9?

 

Any of the unraid guru's able to have a look at my log/shot and suggest what actions I should be taking from here to get my system working a-ok again please? I'm not sure where to start or what to do without risking my data.

 

System specs are as follows:

Asus P5Q-Deluxe - AHCI mode enabled

E6400 (currently underclocked to 1.6ghz)

2gb G.Skill Ram

2xAdapatec 1430SA cards - BIOS disabled.

Seasonic M12-700W PSU

Lian Li PC-A17B

3xNorco SS-500 5in3 hotswap modules

Lexar JumpDrive Firefly 4gb Unraid 4.4.2

syslog.zip

Hopefully you've already resolved this by now, but just in case:

 

With those read errors on disk 9 in the log, I'd immediately move the data off of that drive onto others - you appear to have plenty of free space to accommodate it.  You could either use Midnight Commander from within a telnet session to the server, or use the disk shares (\\tower\disk9 for example) and move the data that way.

 

Then once that data is safe, follow the instructions here - http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems  to check the filesystem on drive 9, as well as a smart report - http://lime-technology.com/wiki/index.php?title=Troubleshooting#Obtaining_a_SMART_report

 

Depending on the results of those, you can either start using the disk again or replace it.

Start with doing the SMART report. Post the results before plotting next step. 

hey guys thanks for the replies. No i havent done anything with the unit yet. Haven't had enough time to sit down and do some serious troubleshooting with it and no one replied to my post to give me any pointers where to start so its just been sitting in the corner being neglected.

 

I've just run the smart report on the disk and attached it to this post.

 

I've tried to also run a -tlong SMART test and get the following:

 

smartctl version 5.38 [i486-slackware-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 219 minutes for test to complete.
Test will complete after Wed Jul 28 11:14:34 2010

Use smartctl -X to abort test.

 

and then it returns to the prompt and stops accessing the drive within a few seconds.

smart.txt

You started the drive test. Now you need to wait at least the 219 minutes before it might be done, as it stated "Test will complete after Wed Jul 28 11:14:34 2010". That is only a rough estimate. Sometimes the tests take longer.

You started the drive test. Now you need to wait at least the 219 minutes before it might be done, as it stated "Test will complete after Wed Jul 28 11:14:34 2010". That is only a rough estimate. Sometimes the tests take longer.

 

ah ok.. i just thought it musta been buggin out coz it wasnt accessing the drive (ie no flashing red light for drive access on that drive).

The test is done internally by the drive.

 

Also, a "long" test may take far longer than the "smart" estimate.  With a large drive today it may not be possible to read it in its entirety in 219 minutes.

 

Edit: I see this disk is a 1TB.   At an average read rate of 100MB/s it would take 10 seconds per Gigabyte or 10,000 seconds per TB.  Looks like your read rate is closer to 75MB/s.

 

10,000 seconds = 166 Minutes.

thanks for the replies..

 

I will post up the results of the smart report once i get home from work today. That should be plenty of time for it to have completed the long test.

OK left the drive to run that test for about 8 hours so surely its finished by now..

 

here is the updated SMART report

smart.txt

Your smart report looks fine - although looks like you are keeping the drive is an icebox!

 

Usually problems with a drive with clean SMART reports turn out to be some sort of cabling / drive cage connection issue.  These are usually accompanied, however, with logged errors which show up at the bottom of the SMART report.  (This makes sense because if the signal between computer and drive is not clean, the drive will be getting corrupted requests that it does not know how to process.  These are logged by the drive.)  However, your SMART report has no such logged errors.  I still think that the drive connection is your most likely culprit.

 

I would suggest checking to ensure that the SATA cable is connected securely on both the "computer end" and disk end.  Sometimes just unplugging and replugging a cable can dislodge an obstruction causing intermittent problems.  Or you might want to just replace the SATA cable with a new or known good cable.  Locking SATA cables can be helpful.  I have a motherboard SATA port that is a little loose and if I try to use a regular SATA cable it gives problems.  Using a locking cable was my solution.

 

If you are using drive cages the problem may be in the internal wiring / connections within the drive cage.  You might try moving the drive to a different location and see if it resolves. 

 

Good luck. Let us know how it goes!

Your smart report looks fine - although looks like you are keeping the drive is an icebox!

 

Yeah I really dont trust the Samsung drive temp reporting. All the other drives in the system (combination of WD's and Seacrates) run about 10 deg hotter than the two Samsungs.

 

Locking SATA cables can be helpful.  I have a motherboard SATA port that is a little loose and if I try to use a regular SATA cable it gives problems.  Using a locking cable was my solution.

 

Unfortunately the Norco SS-500 doesnt seem to support locking sata cables. The ports on the back of the module are too tight or lack the locking clip or something as I did try the locking cables when I first bought them.

 

As an update to my problem above, I broke the server down over the weekend, replaced the SATA cable to the drive and reseated the cradle for the drive in the backplane. After I fired it back up I ran a parity check and 5ish hours later all it came up with no sync errors and no drive errors. So I'm not sure if it was a failed SATA cable or the caddy had a connection issue but it all appears to fine for now. Will definitely be running more regular parity checks from now on.

 

As a side issue I am now looking at updating to 4.5.6. I currently have 4.4.2 installed. Will I need to get the new syslinux to put 4.5.6 on the mem stick or should I be ok with the one I have? I've read of some people having to reformat their memsticks when upgrading to 4.5.x versions.

 

Odds are you'll be fine.  (You'll know for sure soon enough)

Odds are you'll be fine.   (You'll know for sure soon enough)

 

Thanks Joe.. Will try this evening after I get home from work...

Updated last night from 4.4.2 to 4.5.6 with no need for new syslinux etc. Went smoothly.

 

I did a complete parity check on 4.4.2, renamed bzroot and bzimage to .old and copied the new files. After rebooting I ran another complete parity check and all passed. Zero sync errors and zero drive errors.

 

Most happy with the increased speeds copying to the protected array. I dont use User Shares nor a cache drive. I just copy straight to the array with TeraCopy.