I need some advice on what to do next. On saturday I discovered my first disabled disk, it had 2 errors. I don't understand what happened with the drive and what made unRAID decide to disable it. Here's the extract from my syslog:

Apr 17 10:29:21 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:21 Tower kernel: mdcmd (198438): spindown 3
Apr 17 10:29:31 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:31 Tower kernel: mdcmd (198440): spindown 3
Apr 17 10:29:33 Tower unmenu[1139]: cat: /sys/block/sdd/stat: No such file or directory
Apr 17 10:29:34 Tower unmenu[1139]: cat: /sys/block/sdd/stat: No such file or directory
Apr 17 10:29:41 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:41 Tower kernel: mdcmd (198444): spindown 3
Apr 17 10:29:44 Tower unmenu[1139]: cat: /sys/block/sdd/stat: No such file or directory
Apr 17 10:29:51 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:51 Tower kernel: mdcmd (198447): spindown 3
Apr 17 10:30:01 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:30:01 Tower kernel: mdcmd (198449): spindown 3
Apr 17 10:30:11 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:30:11 Tower kernel: mdcmd (198451): spindown 3

 

No writing error occured. I checked the cable and ran a few SMART tests. The reports indicated no read errors and no pending or reallocated sectors.

 

I wonder what I should do next now. Is the drive to be trusted?

I need some advice on what to do next. On saturday I discovered my first disabled disk, it had 2 errors. I don't understand what happened with the drive and what made unRAID decide to disable it. Here's the extract from my syslog:

Apr 17 10:29:21 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:21 Tower kernel: mdcmd (198438): spindown 3
Apr 17 10:29:31 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:31 Tower kernel: mdcmd (198440): spindown 3
Apr 17 10:29:33 Tower unmenu[1139]: cat: /sys/block/sdd/stat: No such file or directory
Apr 17 10:29:34 Tower unmenu[1139]: cat: /sys/block/sdd/stat: No such file or directory
Apr 17 10:29:41 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:41 Tower kernel: mdcmd (198444): spindown 3
Apr 17 10:29:44 Tower unmenu[1139]: cat: /sys/block/sdd/stat: No such file or directory
Apr 17 10:29:51 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:29:51 Tower kernel: mdcmd (198447): spindown 3
Apr 17 10:30:01 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:30:01 Tower kernel: mdcmd (198449): spindown 3
Apr 17 10:30:11 Tower emhttp: disk_spinning: open: No such file or directory
Apr 17 10:30:11 Tower kernel: mdcmd (198451): spindown 3

 

No writing error occured. I checked the cable and ran a few SMART tests. The reports indicated no read errors and no pending or reallocated sectors.

 

I wonder what I should do next now. Is the drive to be trusted?

If the drive was disabled, then a write to it failed.  It is the ONLY way a disk is marked as RED.

 

The cause could be varied, anything from bad disk, intermittent cable (either SATA or power) timeout (took too long to spin up) .  You would need to post the complete syslog for anybody to even take a guess.

 

Right now you are able to get to the contents of the disk by virtue of the parity disk in combination with all the other data disks.

 

Whatever you do, do NOT press the restore button.  That will immediately set a new Disk Configuration and immediately invalidate parity. 

 

To get your disk back on-line, You'll need to:

Stop the array

Un-assign the failed disk

Start the array with the disk un-assigned (This will cause the array to forget its model/serial number)

Stop the array once more

Re-assign the disk to its slot (It will think it is a new disk since it forgot the model/serial number in the step above)

Start the array by pressing the "Start" button to allow it to re-construct the contents of the "failed" disk onto the "replacement" disk. 

 

Once the replacement disk is completely written, you'll have parity protection once more, until then, a second concurrent drive failure will possibly result in data loss.

 

Post a full syslog.  Zip it and attach it to your next post.

 

Joe L.

 

 

 

Joe, thanks for the quick reply!

 

The data rebuild is underway. I'll let you know tomorrow if there were any errors during that. Attached is the full syslog. The only passages of interest are what I posted earlier and the first lines of the syslog. The first line indicates unRAID rebooted at 4am. The reason it did that are unknown. Maybe it's just something so simple a power failure? The rest of the syslog shows unRAID trying to spin down disk3 (red ball disk) every 10s.

syslog-2010-04-17.zip

Joe, thanks for the quick reply!

 

The data rebuild is underway. I'll let you know tomorrow if there were any errors during that. Attached is the full syslog. The only passages of interest are what I posted earlier and the first lines of the syslog. The first line indicates unRAID rebooted at 4am. The reason it did that are unknown. Maybe it's just something so simple a power failure? The rest of the syslog shows unRAID trying to spin down disk3 (red ball disk) every 10s.

The server did not reboot, the system log process saved the old log file as syslog.1 and started a new log.  It automatically does that when the log file gets over a given size.

 

You can get to the old log by entering

http://tower/log/syslog.1

in your browser.

Joe,disk 3 was rebuilt with no errors. I can't access syslog.1. I guess it was deleted when I rebooted the server manually after saving the log file I attached in my previous post. Had I known unRAID saves old log files over 3000 lines, I'd have checked it before rebooting. It would have given us insight as to what happened.

 

Appreciate the help! Cheers.

Joe,disk 3 was rebuilt with no errors. I can't access syslog.1. I guess it was deleted when I rebooted the server manually after saving the log file I attached in my previous post. Had I known unRAID saves old log files over 3000 lines, I'd have checked it before rebooting. It would have given us insight as to what happened.

 

Appreciate the help! Cheers.

Yes, the file was gone once you rebooted.

 

It is not a line limit, but a size limit.  syslogs are rotated if they grow over 1 Meg in size. 

I think it will save at most 2 logs as it is currently configured in /etc/logrotate.conf.