Since I don't come across drive errors often, I just noticed that the current RC version of unRAID along with unMENU will become completely unresponsive if a disk hardware error is encountered.

 

The web GUI will no longer be accessible.

 

unMENU will no longer be accessible.

 

Telnet will continue to work, however, if a manual attempt to unmount all drives cannot be executed due to a busy disk, trying to identify the process "holding" the disk via the fuser command will appear to become unresponsive as well.

 

SMB and NFS mounting and access may appear to work for some time but eventually lead to unresponsiveness from the server, even if the drive being accessed is not the drive experiencing errors.

 

The only recourse is a forced hard reboot.  But eventually unRAID/unMENU will once again become unresponsive.

 

Temperature overheating e-mails will still continue to be issued if enabled under unMENU.

 

The syslog appears to still be updated with notable events.

 

If a parity check is initiated after reboot, parity status e-mail updates will cease when unRAID web GUI also becomes unresponsive.

 

Attached is my syslog showing that drive ata9 (md12 aka disk12 aka sdi) as the problematic drive experiencing hardware issues:

 

Jul 16 04:36:07 UnRAID kernel: sas: sas_ata_task_done: SAS error 2

Jul 16 04:36:07 UnRAID kernel: ata9: failed to read log page 10h (errno=-5)

Jul 16 04:36:07 UnRAID kernel: ata9.00: exception Emask 0x1 SAct 0x1 SErr 0x0 action 0x6 t0

Jul 16 04:36:07 UnRAID kernel: ata9.00: failed command: READ FPDMA QUEUED

Jul 16 04:36:07 UnRAID kernel: ata9.00: cmd 60/00:00:6f:53:e0/02:00:7d:00:00/40 tag 0 ncq 262144 in

Jul 16 04:36:07 UnRAID kernel:          res 01/04:04:6f:51:e0/00:00:7d:00:00/40 Emask 0x3 (HSM violation)

Jul 16 04:36:07 UnRAID kernel: ata9.00: status: { ERR }

Jul 16 04:36:07 UnRAID kernel: ata9.00: error: { ABRT }

Jul 16 04:36:07 UnRAID kernel: ata9: hard resetting link

 

Not sure of the specific nature of the hardware problem but I believe this is a serious issue as unRAID should NOT be locking up when a hardware error is encountered, but instead be able to report that to the user.

syslog.txt

---

FYI, the nature of the hardware error was a failed SAS->SATA breakout cable (from the SASLP).  I initially swapped in a spare drive but continued to get GUI lockups and errors.  The replaced the break-out cable with a brand new one and that resolved the hardware issues.

 

Now Lime-Tech needs to figure out a way to keep the GUI from locking up when this type of hardware error occurs.

Okay,

 

I'm now stumped.  I thought I identified the right drive exhibiting this error as it seemed to clear up, but now it's back and I just can't identify accurately from just the syslog and it's extremely frustrating that RC5 simply becomes completely unresponsive.

 

The only "error" that unRAID reports is this:

 

Aug 14 16:31:27 UnRAID kernel: ata9: sas eh calling libata port error handler

Aug 14 16:31:27 UnRAID kernel: ata9.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0 t0

Aug 14 16:31:27 UnRAID kernel: ata9.00: failed command: READ FPDMA QUEUED

Aug 14 16:31:27 UnRAID kernel: ata9.00: cmd 60/00:00:5f:52:e0/02:00:7d:00:00/40 tag 0 ncq 262144 in

Aug 14 16:31:27 UnRAID kernel:          res 41/40:00:07:54:e0/00:00:7d:00:00/40 Emask 0x409 (media error) <F>

Aug 14 16:31:27 UnRAID kernel: ata9.00: status: { DRDY ERR }

Aug 14 16:31:27 UnRAID kernel: ata9.00: error: { UNC }

Aug 14 16:31:27 UnRAID kernel: ata9.00: configured for UDMA/133

Aug 14 16:31:27 UnRAID kernel: ata9: EH complete

 

unRAID does identify the type of drive during boot:

 

Aug 14 08:23:01 UnRAID kernel: ata9: sas eh calling libata port error handler

Aug 14 08:23:01 UnRAID kernel: sas: sas_ata_hard_reset: Found ATA device.

Aug 14 08:23:01 UnRAID kernel: ata9.00: ATA-8: WDC WD20EARS-00MVWB0, 50.0AB50, max UDMA/133

Aug 14 08:23:01 UnRAID kernel: ata9.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32)

Aug 14 08:23:01 UnRAID kernel: ata9.00: configured for UDMA/133

 

So it's one of four possible WD 2TB drives, but since it doesn't provide a serial number, I can find no other means to accurately identify the specific problematic 2TB drive.

 

I've replaced the SAS/SATA break-out cable with new, RMA'd a drive I thought was the problem, then finally RMA'd the SASLP card, but the error persists.

 

I then swapped two SATA cables on drives I suspect could be the culprit, one from each of the SAS ports and the "error" appears to now be on "ata8" so I think I identified the right 2TB drive as the other drive is a 3TB.

 

But I don't want to rely on this "trial and error" method and need a fool-proof method of identifying which drive is assigned to a given ata number.

 

The problem is after replacing the SATA cable it appeared the issue was resolved and had a clean parity check so I began a 2TB->4TB upgrade and was in the middle of a rebuild when the error reared it's ugly head and unRAID constantly "freezes" (unresponsive GUI and "hung" rebuild) every time, so now I'm in the precarious position of not having a 100% fully "up" system with one incomplete data disk.

 

Though I still have the original data disk that I had replaced with a larger drive so what I may do is mount the suspect data drive and copy all or as much of files off as possible then reinstall the "upgraded" drive, disconnect the suspect drive, set unRAID to disregard the parity and "trust" all the data drives, build new parity, then finally add the new replacement 2TB drive.  Finish up by re-copying all the files back on to the new data drive.

 

Unless someone else can suggest another option for my situation.

 

Frustrated and at my wits end after spending weeks of waiting for needless replacement/repaired components

 

P.S.  Lime-Tech MUST fix this GUI unresponsiveness that results when certain types of hardware errors occur.  This is absolutely unacceptable for this type of drive management system.

syslog_2012-08-14.txt

This command will give you the mapping on the 5.0beta series:

ls -l /sys/block/[hs]d* | sed -e 's^.*/sys/block^/^' -e 's^/^ ^g' -e 's^\.\. devices ^^'

Unfortunately, it does not on the 4.7 version, as that earlier kernel does not include the "ata" data in the listing of /sys/block

 

 

You can simplify the above command as just

ls -l /sys/block/[hs]d*

but the output lines will be longer and a tiny bit more difficult to read.

I will give it a shot Joe, after I await yet my 10th attempt at rebuilding in order to encounter the bug again and identify the drive; after restoring the original SATA connections to the two test drives, the drive now on ata9 is not the same as when I was constantly hitting this error.

 

As always, I appreciate your assist in all matters with unRAID.  You are in invaluable asset to this community and I thank you for your precious time and knowledge...

Okay I've positively identified the suspect drive (it so happens to be the replacement drive I got from WD) after numerous testing and swapping both power and SATA cables.

 

The problem I am in is that I was in the process of a data rebuild when I upgraded a 2TB to a 4TB when the hardware failure occurred, but I still have the original 2TB data drive untouched.

 

What is the best procedure to get a fully valid unRAID 5.0 (rc5) parity system up from all the stable data drives remaining?  The Wiki page for "Trust My Array" procedure notes that it does not work for any recent 5.x series of unRAID.

 

I'm willing to write-off the entire contents of the failed drive if necessary.

Okay I've positively identified the suspect drive (it so happens to be the replacement drive I got from WD) after numerous testing and swapping both power and SATA cables.

 

The problem I am in is that I was in the process of a data rebuild when I upgraded a 2TB to a 4TB when the hardware failure occurred, but I still have the original 2TB data drive untouched.

 

What is the best procedure to get a fully valid unRAID 5.0 (rc5) parity system up from all the stable data drives remaining?  The Wiki page for "Trust My Array" procedure notes that it does not work for any recent 5.x series of unRAID.

 

I'm willing to write-off the entire contents of the failed drive if necessary.

You simply need to un-assignthe disk you wish to remove from the array and then set a new disk configuration and let it calculate parity on the remaining drives.

 

It has absolutely nothing to do with "trusting" parity, as it is no longer valid once the assigned drives are changed.

 

Stop the array

un-assign the drives you do not wish to be part of the array

Click on the "New Config" button on the web-interface, then start the array.

Parity will once again be calculated on the new disk configuration.

Would this simple procedure you are suggesting account for the fact that another drive was never properly rebuilt and when I reinstall that original drive unRAID indicates its the WRONG SIZE and refuses to do anything with it?

Would this simple procedure you are suggesting account for the fact that another drive was never properly rebuilt and when I reinstall that original drive unRAID indicates its the WRONG SIZE and refuses to do anything with it?

assuming the original drive is functional, and you assign it to the array, yes.  Setting a new configuration forgets all prior disk and size information.  (You need to assign the disks in the new configuration as you wish before starting the array)

 

Because you are setting a new configuration and losing parity protection until parity can be calculated once more, it does not allow you to reconstruct onto a new drive.  It does allow you to re-insert the original data drive and get it accepted in the array.

 

No drive should show as  un-formatted once the new configuration is set and the array started.  DO NOT PRESS THE FORMAT BUTTON if disks with data show as un-formatted. Seek guidance.