Hello,

 

I'm running version 4.5.1 and something happen to my parity drive early this morning.  There was a "red flashing light" next my parity drive.  I looked at my SMART reports for the past few days on the parity HD and it showed this:

 

8/3/10 - SMART overall-health self-assessment test result: PASSED

8/4/10 - SMART overall-health self-assessment test result: PASSED  but there was a "ATA Error Count: 1"

8/5/10 - Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

 

I stop the array, shutdown and restarted.  Now the parity drive has a "blue light" next to it.  It asking me to do one of the following choices:

 

1. Start will bring the array on-line and start Parity-Sync.

2. Restore will initialize the stored array configuration; all drives will appear as New, but data disk contents are not affected.

 

My data contents appears to be intact prior to me restarting the system.  I'm assuming my parity HD had some sort of hickup and stop responding to computer.  Resulting in the parity drive going red.  Maybe its starting to go bad? 

 

Does anyone know what I should do in this situtation?

 

Thanks,

Scott

 

 

   

DO NOT PRESS THE RESTORE BUTTON.  It wouldn't be catastrophic if your case, but still there's no reason to do it.  Don't start the parity sync either, do the following first:

 

Your parity drive had a read error.  That could have been caused by a number of things, most likely:

1) A bad or loose data cable

2) A bad or loose power cable

3) A bad hot swap bay (if you use them)

4) A bad drive

5) A bad power supply

 

I would check them in that order.  First and foremost, shut down the server and reseat the connections to your parity drive.  It could have been something as simple a loose connection.  If you see a lot of CRC errors in your SMART report, then this is likely the culprit.  If that doesn't work, then replace the cables.  That doesn't work, just keep going down the list.

 

The blue ball means that unRAID thinks you are upgrading the parity drive.  Starting a parity hopefully still has valid parity data on it, there's no reason to erase that data by pressing either the restore or start button.

 

Post a syslog if you want more specific guidance.

The blue ball means that unRAID thinks you are upgrading the parity drive.  Starting a parity hopefully still has valid parity data on it, there's no reason to erase that data by pressing either the restore or start button.

 

Post a syslog if you want more specific guidance.

 

I have all my HDs within a hot swappable case.  I will verify the five things you mentioned tonight.  Then I will manually run a SMART report to see if any errors occur. Assuming I don't see any error, should I "start" the array which will cause it to do the Parity-Sync?

Yes.

Just to correct some misinformation...

 

Your parity drive had a read error.

 

Perhaps, but a 'red ball' means the drive has been disabled, and that only happens as a result of a write error.

 

The blue ball means that unRAID thinks you are upgrading the parity drive. 

It means that a "new" drive has been detected in the slot.  That is, relative to the last time the system was rebooted, the drive in the slot is different than it was last time (or last time was no drive, and now there is one).  In your case, where Parity got disabled, this should not happen by merely powering down and restarting.  You have to power down, remove drive, power up, power down again, replace drive, power up, and now you see a blue dot.  Alternately you can go to Devices page, unassign Parity slot, power down, power up, go to Devices page, assign Parity again, now should see blue dot.

 

Starting a parity hopefully still has valid parity data on it, there's no reason to erase that data by pressing either the restore or start button.

Strictly speaking this will not "erase" the data, but merely "over write" it, probably with same data that was there before (except of course for the block which got the original write error that led to it being disabled).

 

Probably what I would do in your case is check cabling and reseat the drive.  Then start a parity sync (ie, start array), then follow with a parity check.  If this happens again, replace the drive.

So I sprayed compressed air around all the HD cages and carefully reseated each HD.  I then ran a SMART report and every drive PASSED.  I start the parity-sync but its running EXTREMELY slow according to the status:

 

Total size: 1,465,138,552 KB

Current position: 542,756 (0.0%)

Estimated speed: 1,496 KB/sec

Estimated finish: 16293.0 minutes

 

Based on this it will take 11 days to complete the parity-sync!  I don't remember my system ever running this slow before.  Am I missing something here?

 

The system I have is a old Pentium 4 2.4Ghz Hyper-thread with 2GB of RAM.  I have six SATA Seagate 1.5 TB HD connect to a PCI SATA controller.  All the hardware I'm using was listed on the Wiki as supported.  I typically get 10 MB/sec transfer rate when copying files to my UnRaid over my 1Gbit Network.

 

According to this benchmark page:

http://lime-technology.com/wiki/index.php?title=User_Benchmarks

 

I putty into my UnRaid server and ran top which showed CPU utilization around 0.00% which doesn't seem right.  I've attached my syslog and the most recent SMART report on my hard drives.

 

Anyone have any suggestions?

 

Regards,

Scott

syslog.txt

20100805_smart_summary.txt

My_UnRaid_Console_Settings.pdf

Check the actual SATA cable for that drive or better yet just replace it, hopefully with a locking cable.

 

I'm thinking somehow the array got stopped and then started again or rebooted with that drive not connecting and then the next stop/start or reboot made it appear as the new disk.

 

At the bottom of the syslog it appears that disk ATA9 is giving problems.

 

Check your syslog while the parity build is working and see if there are more errors like those for ATA9. It appears this corresponds to device sdf or disk0 which is the parity.

 

I also see here that it thinks the disk was replaced;

 

"Aug  5 17:58:59 sumner-nas kernel: md: disk0 replaced"

 

One odd thing is that it appears that the array was started and the disks mounted and the parity sync started yet about 5 seconds later all the disks spin down. I don't see the parity sync getting cancelled and that is an odd spin-down time anyways.

 

Peter