I have now had two occasions where unRAID disabled Disk 2 of my 10 Media Disk + 1 Parity Disk array that have occurred in the past 2 weeks while writing to the disk.  In each case, Disk 2 assumed a red ball.  While disabled, hdparm returned "HDIO_GET_IDENTITY" failed.  Syslog attached from most recent event.  When powered down, I checked (but did not replace) the cables, which seemed to be OK, removed the drive tray and reinserted the drive tray, restarted and unRAID rebuilt the array and after the rebuild all drives have green balls.  After the rebuild, I ran smartctl on Disk 2 and the results are attached.  I am running v4.2.3 Pro.

 

Would someone please interpret these results and advise if this is a drive problem or something else and what my next step should be?

 

Thanks,

 

Dan

That syslog is only the last page or 2 of it.  We really need the entire syslog, captured as a file.  Please see the Troubleshooting link in my sig, for instructions in capturing a syslog.

 

The syslog piece does show that the system has lost contact with your unRAID flash drive, and may have lost contact with Disk 2, but I need to see the whole syslog.

 

The SMART report shows that this drive has had a few issues in the past, but they are not recent, so are probably not involved in the current problems.

Rob,

 

Thanks for the reply.  Sorry I screwed up the syslog; I seem to be having trouble copying the syslog to the flash drive--probably an operator problem.  Anyway, I have stopped and rebooted the array and will try some writes to the disk I'm having trouble with and when I get write errors, I'll try again to capture the syslog and post it here.

 

Thanks,

 

Dan

I seem to be having trouble copying the syslog to the flash drive--probably an operator problem.

 

Probably not.  In your syslog piece, the flash drive was not accessible.  Try saving it to Disk 1:

cp /var/log/syslog /mnt/disk1/syslog.txt

 

Also, copy a syslog as soon as possible, after booting, hopefully before the trouble starts, so you have at least one syslog to examine, and use as a baseline.  Copying a syslog again, *after* the problems is more useful of course, if you can.

 

If the system seems fine after booting, try installing UnMENU.  You can save a syslog from within the Syslog extension.

Well, the trouble returned on Disk2.  I have attached the syslog.  Please advise what the problem is.

 

Thanks,

 

Dan

After almost a month of apparently perfect operation, at 12:19AM, you had an exception Emask error (frozen, timeout), an error which seems to be more and more common this year.  It seems to indicate that the drive became unresponsive, could not be reset, and was finally disabled, which resulted in all of the other errors.  It seems too coincidental that it is Disk 2 again, but I can't conclude that there is anything wrong with this drive, and this error often (but not always) seems related to spin down or spin ups, on secondary drives on the same channel.

 

I think in every case I have seen, the drive is fine, with no damage.  You will have to power off and reboot, but the whole array should be fine, with perhaps a few parity errors to fix on the subsequent parity check.

 

If the drive comes up disabled, re-assign the drive if necessary, and carefully follow the instructions in this How To:  Make unRAID Trust the Parity Drive.

Rob, thanks very much for the analysis.  One reason that it has been a while since I had a problem is that after the last problem, I moved all files off of that drive to ensure that I could access them and would not lose them and I just haven't written anything to that drive until now.  The error this time occurred when I was backing up (writing) a new bluray movie to the drive.  The process went OK for a few minutes and then the write operation failed and the activity LED on the drive tray stayed on permanently until I pulled the tray.  So, I shipped the drive to Seagate for replacement yesterday; I figure the worst is that they will find the drive OK and I will have to pay for return shipping also--but at least if that occurs I will know that the drive is probably good and that there is something else to chase.  Once they send me my old drive or the exchange, I will do as you advise.

 

Thanks again!!

 

Dan

Unfortunately, there is one other possibility.  You mentioned it is in a tray, so perhaps there is something wrong with the drive connections of that tray.  I would have to consider that tray suspicious.

Good observation; when I get my drive back, I'll put it in a different tray as I  have 4 empties left.  I checked the SATA cable connections on the MB and 5-in-3 backplane and both ends looked and felt OK and are of the locking type.