Seagate ST2000DL003-9VT166

tadgy wrote:
Hi, If you've RMA'd any of these in the UK, can you please let me know your experience and if there are any references to tickets within the Seagate "system" that I can reference as the same issue (hopefully to make the RMA process less of a ball-ache). Thanks :)

This is a great idea, would anyone who successfully managed to RMA these drives please let us knwo what your tickets were so we can use these hopefully to get our dodgy drives changed?

I presently have three RMA's open for three drives with this problem, below are my numbers if you want to reference them when you contact seagate.
1006868185
1006868190
1006868194

Hi,
I'm happy to say that i've had a very positive experience with Seagate on this issue.

I called the European support number listed on their website and got through to a very nice chap called Hans W (who was actually in the Netherlands). I explained the situation with the drive firmware, and that I would need replacement drives with a specific firmware version.

Luckily, he had heard about this problem previously from a colleague so was aware that they needed to do 'something' about the drives. He asked me to email him the details and the URLs for the Netgear article on the subject, the forum thread (this one) and the Netgear HCL for the NAS.

After a couple of days, I got call back - good news! He'd looked at the links i'd posted and was happy to replace the two dodgy drives with a completely different model, the ST2000DM001 (the same model as someone earlier in the thread mentioned they received as replacement). I was told he'd specifically picked this model as it was listed on the HCL for the NAS and has the same cache, SATA spec and size as the crappy ones.

The replacements are the re-manufactured drives, which I was a bit annoyed about (since my drives were originals and the only fault was Seagate's own crappy firmware), but i'd rather have two working drives than a couple of paperweights. The new drives are a slightly better performance spec, being 7200 not 5900 speed; so I can't really complain... i'm just being picky :)

I'd also explained to Hans that I needed to swap out the drives before I could send the faulty ones in to them - obviously because I needed to replace them one at a time and allow the array to re-sync. He was quite happy to send out the replacement drives on good-faith - he didn't even take a credit/debit card number to insure I did actually return them... but from what i've read in this thread, I don't think the European support can do that. All I will say about them offering to do that is, if they offer the same service to you; don't abuse it - they could quite easily refuse to send the new drives out before receiving the broken ones first. So lets keep the ball rolling on the trust, yeah? :)

The replacement drives arrived quickly (via UPS), and i've returned the dodgy ones in the packaging the new ones arrived in. From my first call to Seagate to receipt of the replacement drives was about a week.

All in all, i'm very satisfied with how Seagate have handled this - and I have nothing but praise for Hans W, who took the time to research the issue here and select the replacement model by checking the HCL himself.

If anyone would like to reference my RMA process with Seagate (I'm not sure if this number is valid worldwide, or just in the European system), feel free to do so: 2101878723.

I hope people can have my luck with this - it sounds like i've had a very smooth ride! :)

Darren.

PS: If you ever check this thread again Hans W from Seagate support in NL, you have my great thanks :) And know that my relay of this support experience to business colleagues has led them to consider Seagate very highly for future purchases.

All. I ended up with an Ultra 6 and 8 of these drives with model # suffix 301 & FW CC32

During a support call for an attempted RMA seagate simply said that the drive is not supported in a raid config. (And its not their problem to fix) It's a desktop drive. Not a NAS drive. There are good articles on the net that covers TLER and RTS - in simplistic terms the drive times out and the raid config SW/HW marks it as dead. It times out as the drives internals try and recover bad blocks and this takes a bit of time.

With 8 drives the rate of bad blocks recovery is surprising. I have had 3 double drive failure in 5 weeks. Swap them out - only to find others dead --- level of instability is scary to say the least with precious family home videos now lost as a result.

I read a few threads on adjusting drive timeout values in Linux - noting that no one claims success & not having much else to do I applied the method and have flogged the unit for 2 weeks now with no dead drives. It seems pretty stable. I cant say if its just luck or if it actually works. Time will tell- if you would like to try it - here it is.

After a reboot (can be automated via /etc/rc.local), I run the following commands:-

echo 300 > /sys/block/sda/device/timeout
echo 300 > /sys/block/sdb/device/timeout
xxxx

Default is 30 - I do this for every drive in the raid group. In the Ultra 6 it ends up being for sda, sdb, ..... sdf
Give t a try..... If it continues to works ... it saves me going and getting WD red NAS drives.

ndroberts1 wrote:

All. I ended up with an Ultra 6 and 8 of these drives with model # suffix 301 & FW CC32 During a support call for an attempted RMA seagate simply said that the drive is not supported in a raid config. (And its not their problem to fix) It's a desktop drive. Not a NAS drive. There are good articles on the net that covers TLER and RTS - in simplistic terms the drive times out and the raid config SW/HW marks it as dead. It times out as the drives internals try and recover bad blocks and this takes a bit of time. With 8 drives the rate of bad blocks recovery is surprising. I have had 3 double drive failure in 5 weeks. Swap them out - only to find others dead --- level of instability is scary to say the least with precious family home videos now lost as a result. I read a few threads on adjusting drive timeout values in Linux - noting that no one claims success & not having much else to do I applied the method and have flogged the unit for 2 weeks now with no dead drives. It seems pretty stable. I cant say if its just luck or if it actually works. Time will tell- if you would like to try it - here it is. After a reboot (can be automated via /etc/rc.local), I run the following commands:- echo 300 > /sys/block/sda/device/timeout echo 300 > /sys/block/sdb/device/timeout xxxx Default is 30 - I do this for every drive in the raid group. In the Ultra 6 it ends up being for sda, sdb, ..... sdf Give t a try..... If it continues to works ... it saves me going and getting WD red NAS drives.

Intesting, I like to hear how stable this is after a few months. Are there any caveats to changing the value above? Unfortunately, I already bought 2 WD 3TB RED drives and yanked the Seagates from slots 1 & 2. However, I still would be interested how this fix works long term since the Seagate drives may end up back in the NAS should a disk failure occur again.

Hi,

I've got 4 x ST2000DL003-9VT166-302 FW CC3C which have only now started to be marked as "dead". I didn't even know there was an issue with these drives as Pro 4 had been running perfectly for 16months with no issues and had no reason to suspect anything!

A week ago I logged into Frontview to be informed that Slot 1 was dead. Cue mad panic to quickly backup everything to my Nas Duo and external USB drives. Also cue forum searches to identify problem. Found this forum and thought great problem solved. In the interim whilst conducting backups I restarted the Pro4 and was then advised via Frontview that all drives were dead! However the strange thing was I could still create back-up jobs and run them successfully and also navigate NAS via Windows Network. Sunday night I lost comms over network with the Pro4 and restarted it to be told I now had Slot 1 and 4 dead and the RAID was unprotected (Slots 2 & 3 Green ok). Again I could still run backup jobs to external USBs. Then it finally lost network comms with any login attempt to Frontview now greeted with Contact Support message.

So I've powered off Pro4 and removed slot 1 HDD. Have run Seatools for DOS long test which passed and it reports that SMART has not been tripped. I then proceed to conduct firmware upgrade as per http://www.readynas.com/forum/viewtopic.php?f=24&t=64510 (ps how do I enter url code in posts?) which appears to run ok until the very end when I get a failed message and "Model matched but firmware version not compatible." I've tried twice to upgrade the firmware and it has failed. I'm trying to raise email ticket with Seagate but for some reason this isn't working so will phone them tomorrow but in the interim:

Any ideas how to get this fixed (force firmware upgrade? http://forums.seagate.com/t5/Desktop-HDD-Desktop-SSHD/ST31500541AS-force-upgrade/m-p/79104/highlight/true) or is my NAS dead with these drives?

I read a few threads on adjusting drive timeout values in Linux - noting that no one claims success & not having much else to do I applied the method and have flogged the unit for 2 weeks now with no dead drives. It seems pretty stable. I cant say if its just luck or if it actually works. Time will tell- if you would like to try it - here it is. After a reboot (can be automated via /etc/rc.local), I run the following commands:- echo 300 > /sys/block/sda/device/timeout echo 300 > /sys/block/sdb/device/timeout xxxx Default is 30 - I do this for every drive in the raid group. In the Ultra 6 it ends up being for sda, sdb, ..... sdf Give t a try..... If it continues to works ... it saves me going and getting WD red NAS drives.

I. too. am very interested in how this holds up. It still doesn't explain why going back to RAIDiator 4.2.21 has fixed the problem for me, though. To me, that clearly indicates that there is a fix that Netgear could implement if they only had a clue what they changed (intentionally or not) in the 4.2.22 update that affected this. The default timeout in 4.2.21 is also 30, so that's not it. I would like to update RAIDiator on my NAS's, but dare not due to this issue. I keep the ones without the ST2000DL003's at 4.2.21 also, in case the NAS with them has a hardware problem and I need to swap the disks to another.

I ran more than a year and a half with these drives with no problems. Upgraded to 4.2.22 and had problems within a week. Downgraded to 4.2.21 and have been going strong for another year. Yeah, it's a Seagate problem. :roll:

Hi,

I have three ST2000DL003-9VT166 of which one has now reported dead in my ReadyNAS Ultra+ 4. I replaced it, but looking at it afterwards there were no SMART errors, so after googling I found this thread. I have the 302 version with CC3C but unfortunately the firmware upgrade to CC3D is no longer to be found anywhere. The warranty ended earlier this summer, maybe that is why? All the links I have found to the CC3D software (e.g. https://apps1.seagate.com/downloads/certificate.html?key=156192206224) are broken ("Certificate Unavailable"). Does anyone have an idea of where I can find this firmware upgrade?

Best regards,
Andreas

Did you look here? https://apps1.seagate.com/downloads/request.html

Yes, but when I enter the details I just get "no firmware updates available", even though I have the CC3C.

Regards,
Andreas

Although "ST2000DL003-9VT166" appears to be very specific, there are apparently several variants (manufactured in different locations) that use different firmware. That is why the seagate tool asks for the serial - the product model alone is not enough to tell you the firmware.

You can perhaps ask in the Seagate forums, but I suspect they will tell you there is no firmware update available for your specific disks.