Disk Failure Detected...

[Royan]

Add another case...

ReadyNas Pro 2 (RAIDiator-x86 4.2.17)
two Seagate ST2000DL003-9VT166 (CC32) disks.
One disk reported itself as dead and 'SMART+' greyed out

In my case it happened while runnning the 'bliss' plugin.
The plugin had a lot to do, and there was a lot of disk activity when it happened.

I didn't have to yank the drive.
After a restart and running smartctl from the shell, it all of a sudden decided the disk was ok, and started rebuilding the volume.

Now I'm thinking of replacing both disks (3 weeks old!), just in case it happens again...
So then it's just a case of finding a set of disks that are on the HCL, available from my retailers and doesn't have any black marks against them in the forum...

Edit:
Oh, and I'm not running a mac, and there was no errors in the smart data/logs...

brgds
Royan

[Upstate]

...and add another one.

The Google gods led me here and I just had this same exact issue on a month old 2100.

Disk 2 gave up the ghost, hot swapped in another disk that wasn't recognized. Swapped in the reported Dead disk and with a cold restart was happily resyncing. A warm reboot did not do a thing.

My unit has the ST32000644NS and like everyone else FV reported the drive as dead, with no SMART errors and this is on 4.2.17.

And in keeping with the theme of the thread, I also have these same errors repeating in the system log:

Code: Select all

Aug  2 16:44:04 HPNAS1 kernel: ata2: hard resetting link
Aug  2 16:44:04 HPNAS1 kernel: ata2: link is slow to respond, please be patient (ready=0)
Aug  2 16:44:04 HPNAS1 kernel: ata2: COMRESET failed (errno=-16)


And for the final kicker, we are also running OSX and AFP. Timemachine was enabled on 7/29 and the dying disk issue occured on 8/2.

Judging from the similarities posted I have disabled TM on our macs and will also do so on the NAS. Interestingly my other 2100 that is RSync'd with the first has no issues at all and is also not using AFP or Timemachine.

I am going to pilfer through the logs on the macs and see what TM was doing at the time of the supposed disk failure and wil report back any interesting findings.

Fits in nicely with:

Reading back through this, there seems to be a commonality in our disks being erroneously reported as dead and the use of OSX.

Summary: (user: details)

bluewombie: Ultra 6 (not plus), OSX Snowleopard, AFP
imlucid: Pro Pioneer, OSX Snow Leopard and Leopard, Time Machine
citizenplain (me): Ultra 6 Plus, OSX Snow Leopard, AFP file transfer, Time Machine
evanhatesspam: Ultra 6 Plus

None of us have had abnormal results from any disk checks. All of us are having trouble with the Seagate ST2000DL003-9VT166 drives.

Didn't catch if user bluewombie has Time Machine enabled. Not sure how evanhatesspam is accessing his NAS.

I updated to the new firmware (RAIDiator-x86 4.2.16) recently, but haven't had a need to do a large file transfer since updating. The updates described in the change log for this version didn't sound like they specifically address this problem. We'll see if it makes a difference.

Anything I'm missing here or any other details we could add to this? Bluewombie, did you ever get anywhere with tech support?

Updated...

Summary: (user: details)

bluewombie: Ultra 6 (not plus), OSX Snowleopard, AFP
imlucid: Pro Pioneer, OSX Snow Leopard and Leopard, Time Machine
citizenplain (me): Ultra 6 Plus, OSX Snow Leopard, AFP file transfer, Time Machine
evanhatesspam: Ultra 6 Plus
upstate: 2100 v2, OSX Snow Leopard and Leopard, AFP file transfer, Time Machine

[PiddeP]

I've experienced the exact same problem, but with another Seagate model (ST31500341AS). They worked flawlessly with my Duo but when I switched to an Ultra 2 the problems started.

My system.log is filed with cycles like this one:
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1: limiting SATA link speed to 1.5 Gbps
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: failed command: FLUSH CACHE EXT
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Aug 11 10:48:06 nas-8B-21-2C kernel: res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: status: { DRDY }
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1: hard resetting link
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: configured for UDMA/133
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: retrying FLUSH 0xea Emask 0x4
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1.00: device reported invalid CHS sector 0
Aug 11 10:48:06 nas-8B-21-2C kernel: ata1: EH complete

Two days ago disk 2 turned "dead"/grey in Frontview, but came back alive after I pulled it out, rebooted and then put it back in. After a few hours it hade re-synced.

This has now happened again, but now disk 2 is still showing in Frontview as dead, without being present in the system! I can't make the system identify the slot as empty, and then re-sync as I insert the drive.

What should I do? Could a reboot with both of the inserted do any harm?

Cheers,

Peter

[PiddeP]

This has now happened again, but now disk 2 is still showing in Frontview as dead, without being present in the system! I can't make the system identify the slot as empty, and then re-sync as I insert the drive.
r

Update: I booted up with only disk 1 inserted, inserted a new WDC-disk, which seem to re-sync correctly.

[jah313]

You can add me as well...

Ultra 6+

with 6: ST2000DL003

DISK 4 failed today while copying data from an NV+. I am sending them all back to Newegg and getting Hitachi drives.

[ferg]

I've got six x ST2000DL003 in a new Pro 6. Two from one supplier and four from another. One failed within 3 hours of adding the drive and a second failed within 48 hours of adding it. Both were from separate batches. Either this drive has a pretty poor reliability status (and if so what's it doing on the HCL) or there is something wrong with it (and in which case what's it doing on the HCL!).

[atva]

Same problem:
2 weeks old Ultra 6 (fw RAIDiator 4.2.19) with 6 new Seagate ST2000DL003-9VT166 (CC32) disks.
2 dead drives (3 and 5)
Reinserted 1 and it's now rebuilding.

[jah313]

I now have the Hitachi drives and they have been running since 9/1/11 without a problem.

[atva]

After rebuild of one drive both drives are back to normal status

[bokvast]

+ 1 here... after some reboots it started to resync and now it works, but it really shouldnt be on the hcl.

[ndroberts1]

Same here - Ultra 4 with four ST2000DL003-9VT166 (CC32). Raid 5 + MAC & TM.

Given that so many are having issues with no clear fault n HW.... I would start thinking / suspect the raid SW working with the HW. Still a Netgear responsibility.

Anyway - has anyone prev. reporting errors (some dating back to Mar/Apr & may. come up with what works ?

Thanks.

[PapaBear]

There have been some comments about this drive in a ReadyNAS and Macs. Is anyone having these problems when using a Windows PC?

[bokvast]

yes, i have both, and same issue.

What happend to me was after a diskfailure i let the drives sit in the same bays and doing a reboot, then it started to resync for a second time and now it works.
Still, it has no business being on the HCL

[capaust]

We seem to be having the same issue.

ReadyNAS NVX (RNDX4000), first with RAIDiator 4.2.17 and then with 4.2.19
Four ST2000DL003-9VT166 (CC32) drives, XRAID2

Have had support cases with Netgear open since September and have been through the following steps:

1. After initial failure of two drives at once (drives 3 and 4), tested all drives using SeaTools (ran all standard tests just to be sure) with no errors reported.
2. Started from scratch and completely reconfigured the NAS. Initially all drives worked fine, but drive 4 failed while transferring data back on to the NAS.
3. Reopened Support Case with Netgear. Tried OS Reinstall. No luck. Case was escalated to Level 3 support. After multiple reboots, drive 4 started working again and re-synced.
4. Level 3 sent a new NAS. Moved existing drives to new NAS. As before, while transferring data, a drive failed--this time drive 3.
5. Pulled drive 3 and tested it again using SeaTools. No issues found with the drive. I'm now waiting on the next step from Netgear support.

System Log for these drive failures look basically the same as those already posted. I won't clog up the forum with them now, though I'm happy to post them if anyone wants to have a look.

[bokvast]

my problem has escalated to the worst possible outcome

The NAS did a factory default by itself, 5.5TB data gone. Woke up in the morning and saw that all data was gone and a factory deafult had been made. Contacted Netgear and they gave me a new nas directly.

Either fix the problem, or remove the drives from the HCL!