I just noticied that my spanking brand new unRaid array with about 150 G of movies on it is doing a parity check.  Is there any way I can tell why it did that?  When it started etc?  It does not seem to have any issues and I can watch a movie while it is doing it.

 

The last 6 lines of the sys log are :

Apr 16 17:52:30 Tower kernel: ata2: status=0x51 { DriveReady SeekComplete Error }

Apr 16 17:52:30 Tower kernel: ata2: error=0x04 { DriveStatusError }

Apr 16 17:52:30 Tower kernel: ata2: translated ATA stat/err 0x51/04 to SCSI SK/ASC/ASCQ 0xb/00/00

Apr 16 17:52:30 Tower kernel: ata2: status=0x51 { DriveReady SeekComplete Error }

Apr 16 17:52:30 Tower kernel: ata2: error=0x04 { DriveStatusError }

Apr 16 17:52:30 Tower ata_id[2449]: HDIO_GET_IDENTITY failed for '/dev/block/8:32'

 

And I have no idea if it is telling me anything important.

 

Advice/help appreciated.  I am actually beginning to understand this

The most common cause would be a non-clean power down.  Are you using a UPS?  Did you lose power or turn off your server recently?  The only way to cleanly shut down your server (without the use of add-ons) is through the web interface:

 

Stop the array

Power Down

 

Anything else, like pressing the power button on the server, pressing ctrl-alt-del on the console, or a loss of power will cause a 'hard' shut down.  unRAID will automatically start a parity check when it is next powered on.

That answers it.  I was playing with sleep and WOL.  I can put the system to sleep.  The WOL magic packet wakes up the server, power comes on, but can't telnet to it, display is blank (no signal), keyboard does not seem to be working, but LAN has lights flashing.. I need to look at that again tomorrow but I will first stop the array. I am playing with various options on s2ram.

 

I had to force shut it down and reboot it hence the parity check.  Thanks.

The last 6 lines of the sys log are :

Apr 16 17:52:30 Tower kernel: ata2: status=0x51 { DriveReady SeekComplete Error }

Apr 16 17:52:30 Tower kernel: ata2: error=0x04 { DriveStatusError }

Apr 16 17:52:30 Tower kernel: ata2: translated ATA stat/err 0x51/04 to SCSI SK/ASC/ASCQ 0xb/00/00

Apr 16 17:52:30 Tower kernel: ata2: status=0x51 { DriveReady SeekComplete Error }

Apr 16 17:52:30 Tower kernel: ata2: error=0x04 { DriveStatusError }

Apr 16 17:52:30 Tower ata_id[2449]: HDIO_GET_IDENTITY failed for '/dev/block/8:32'

 

And I have no idea if it is telling me anything important.

Yes, it's telling you something important!  It is is having problems with the disk at ata2.  You should address that ASAP!

It may turn out to be something as simple as bad/lose SATA cable or power cable.  Or something more serious.  You can't ignore that.

 

Post a full syslog!

 

Okay, I really do want to understand what the syslog is trying to tell me.  Let me start by describing the drives in my system

 

There is an IDE 120 meg partitioned into three partitions that is not used at all by unRaid. One partition is NTFS and holds windows XP x64. One partition holds ubuntu, The last partition is not formatted at this time.

 

There are two 2TB Hitachi drives connected to the first two mobo sata ports, the next 4 mobo sata ports have no drives connected to them.

 

There is a SASLP-MV8 HBA with a single Hitachi 2TB drive connected to each of the connectors (0, 4). the other 6 drive trays are empty.

 

The two Sata drives connected to the mobo are in the array.  The other two drives ( connected to the SASLP HBA have not even been formatted yet and just sit in the trays.  It is my intent to "preclear" them this weekend but not add them to the array.

 

I, at my newbie state can not even tell which drive is ata1 and which is ata2 as referred to in the syslog which is attached.

 

Any help/advice greatly appreciated.

Syslog_.zip

I re-orgainized the disks moving the two disks that were on the SAS controoler so they are on the mobo sata connectors.  They are not part of the array.  I intend to preclear them today and then add one to the array.  That will give me 1 parity, two data, and one spare. So far with a clean boot there are no errors in the syslog file.

 

Time will tell.