Disk 9 has failed but can someone tell me why?

Would you like a guess? I can think of a dozen reasons. A syslog would be helpful.

I did add it to my first post but it disappeared.

New_Text_Document_2.txt

Attach a SMART report for disk 9.

I tried to get SMART via Putty but it refused. I will have to get it by plugging the hdd into my pc and use hdtune. Is there anything else wrong in the syslog?

I have checked the SMART values on disk9 and there is abosultely nothing wrong. I am using HDTune to check the drive for errors.

 

Confused!

 

I have rebuilt 15 hdds one after the other and never had this problem (Thats 10 hours to rebuild one disk and then 14 hour parity check per disk)!!

 

I think is the CPU thats caused this problem.

 

Anyone have any ideas?

 

 

I tried to get SMART via Putty but it refused. I will have to get it by plugging the hdd into my pc and use hdtune. Is there anything else wrong in the syslog?

What command did you attempt to use?

 

It should have been

smartctl -a /dev/sdX

 

If it refused, then the connection to the disk was probably intermittent, and you moving the disk physically would have re-seated the connectors.  (The other possibility is it locked up, and power cycling it (while moving it) made it start responding again)

 

Joe L.

I have checked the SMART values on disk9 and there is abosultely nothing wrong.

Post the full smart report... please...  Unless you do not really want any help.  I am doubting you have the same level of experience as the collective minds that assist with analysis.

I think is the CPU thats caused this problem.

What makes you think the CPU is the issue?  I cannot think of ANY reason a CPU would disable a disk.  Help me to understand your reasoning.  (hint: disks are disabled when a "write" to them fail.)

 

Oh yes, please post an entire syslog, not just what you think is important. (looks like you posted an excerpt)  We do not even know which version of unRAID you are running... or the actual status of the disk that failed...

 

Joe L.

I couldn't upload the entire syslog as there was an upload space limit. But I have uploaded the first.

New_Text_Document.txt

Smart report here:

 

The cpu (amd 635) has been giving strange speed readings on parity. And its the only thing I changed. I have now reverted back to the amd 245 and everything is back to normal. I am now rebuilding disk9 at 120MB/s!!!! (using RC5).

If unRAID can't you give a smart report on the drive I wouldn't leave it in the array.  Can you get unRAID to give you smart reports on other drives?

I checked one other drive before shutting down and unraid gave a smart report. I have now replaced disk9 with a new one and put the original disk9 in a Windows 7 computer and so far there are no issues.

I couldn't upload the entire syslog as there was an upload space limit. But I have uploaded the first.

You could try to ZIP it up and upload the zip archive.  That might be small enough.  If not even then then split it up first archive it and then upload the archives to multiple posts.  It's a pain but that will give those that know how to read a log file the info they need.  But that isn't me.  I can usually find most things but I'm still guessing most times when I look at a log file.

As others have said and our guidelines recommend (Capturing your syslog), always try to include a complete syslog, zipped if necessary (they compress very small).  However, your excerpt does appear to give the history of the Drive 9 issue.

 

At Sep 27 19:11:59, you began a parity check.

At Sep 27 23:22:26, mvsas has some failed command issues.  Drive 9 appears to be associated with sde, sd 0:0:3:0, and ata12.00 (based on the limited info here).  There is no explanation for the command failures, and nothing looks familiar to me, so have to call it an mvsas or card 'failure of unknown origin'.  The command failures appear to be associated with sde, Disk 9, and Disk 9 never appears to respond again after this, so you can ignore the associated parity errors here.  (Tom, I wish they were not reported as parity errors here, because these are actually associated with a non-responsive disk.  Shouldn't that have stopped the parity check?)  Various recovery efforts and exception handlers are called, with no apparent success, and ...

Finally, at Sep 27 23:23:24, the kernel marks the drive as disabled.  You can completely ignore ALL of the drive errors that follow that event!

 

There is no evidence of anything wrong with the drive here, and your SMART report confirms that, so you can feel confident the drive itself is fine.

Thanks.

 

I updated the bios on my Asus board from 2001 to 3029. I think this is causing the problem (maybe). I put the old amd 245 cpu back and I still had a cpu stall (check syslog). I think the 3000 series bioses are to implement the bulldozer (crappy) processors. The only way to fix this is to downgrade the bios or get a bullcraper cpu. This is all theory by the way!

 

If the cpu/bios did not cuase this problem then what did???

 

I have successfully rebuilt disk9 and I am 5 hours away from completing a parity check.

New_Text_Document_3.txt

I was running a parity check and disk9 has redballed again. This is the new disk9 to replace the previous disk9.

 

What's going on here???

New_Text_Document.zip

Try a new SATA cable.

I use mini sas 8087 cables connecting the sas2lp to the Norco's mini sas backplane. Each sas2lp has two mini sas connectors and each connectors runs 4 hdds. If the cable was dodgy then all 4 hdds would be screwed up. I will remove the cable and clean it.

Try a known working drive bay.

If the cable was dodgy then all 4 hdds would be screwed up. I will remove the cable and clean it.

Not if only one conductor in the cable had a poor connection, or one drive bay had intermittent connections to either the SATA cable or the disk.

OR

Not if only one bay in the drive cage had an intermittent power connection to disk9 that opens up on vibration/temperature.

 

On my older server a power splitter caused all kinds of similar issues.  No disk I put in a specific drive tray would stay online.  I eventually found it, but I did pull my hair out a bit finding it.  It was several years after I had put the server into service I found it, after expanding the array eventually to use the drive tray with the intermittent power connection.