Most of the attributes seem to be healthy, with none failing now and current nominal values being above the threshold values. A couple are close, but I've seen brand new drives with close values for those attributes 10 Spin_Retry_Count and 184 End-to-End_Error.

 

As for some of the raw values ... There was 1 for attribute 187 Reported_Uncorrect, but the other related attributes, 5 Reallocated_Sector_Ct is 0, 197 Current_Pending_Sector is 0, 198 Offline_Uncorrectable is 0, and 199 UDMA_CRC_Error_Count is 0 as well.

 

I do not know if attribute 195 Hardware_ECC_Recovered has a consumer readable value or not, but it's current nominal value of 36 is above the threshold of 0, even though it's raw value is 164375429.

 

I do not know if attribute 183 Runtime_Bad_Block has a consumer readable value or not, but it's current nominal value of 99 is above the threshold of 0, even though it's raw value is 1.

 

Now on to what could be a concern ... From the report, the drive is powered on for 1339 hours, but had some issue occur at 1293 hours, which was 46 power-on hours ago from when the SMART report was invoked at "Fri Jan 28 18:53:44 2011 EST"

 

I can't tell what happened to cause that issue then.

 

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 9  Short offline       Completed: read failure       90%      1293         25788408

SMART Error Log Version: 1
ATA Error Count: 1
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 1 occurred at disk power-on lifetime: 1293 hours (53 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 f8 7f 89 01

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 00 00 b3 83 41 00      07:47:12.581  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00      07:47:12.562  READ FPDMA QUEUED
  60 00 00 00 b1 83 41 00      07:47:12.539  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00      07:47:12.514  READ FPDMA QUEUED
  60 00 00 00 af 83 41 00      07:47:12.500  READ FPDMA QUEUED

 

Only thing I can think of is a troubleshooting induced error as that would have been Wed. when I started troubleshooting. Maybe from switching the power off as it was doing something?

2 long smart checks completed on 11 drives all check good.

 

3 parity checks with no errors

 

all the same equipment cables cards drives being used.

 

the only thing that has changed is the drive use from a cache to a data

 

unraid works as advertised with the drive in a data mode, but crashes with the drive in cache mode on 4.6 and 4.7

 

its outside my realm of troubleshooting at this point.

Current syslog.

syslog-2011-01-29.txt

Just successfully pre cleared a 2tb ears drive. Upon selecting it as the cache drive I was presented with a green dot for that drive on the main page. That used to be a blue dot. even during the process of formating the drive dot remains green. Small things, but not like it used to be on 4.6. Only question is about the message given when the cache drive is spun up and down what does it mean?

 

this was on an up

 

Feb  2 13:20:41 Tower emhttp: shcmd (210): /usr/sbin/hdparm -y /dev/sdn >/dev/null

 

this was on a down

Feb  2 13:20:57 Tower emhttp: shcmd (211): /usr/sbin/hdparm -S0 /dev/sdn >/dev/null

 

it only does that for any drive assigned as a cache

Those are the actual commands it uses to spin up and spin down the drive.

Why is it only the cache drive uses that command?

Why is it only the cache drive uses that command?

 

It is outside the protected array so is not "really" part of the unRAID per say.

Thanks. Everything is working great again. Nothing changed other than getting the seagate 2tb drive out of the cache spot and putting the wd in. who knows.