Seagate ST31500341AS 1.5TB

My recent purchase of 1.5TB Seagate 7200.11's (http://www.readynas.com/forum/viewtopic.php?f=66&t=28217) revealed that by visiting http://support.seagate.com/modelcheck/modelcheck.jsp and supplying your serial number(s) you can determine whether any action is required.

Hi btarolli,

the check says for my drives that no action is required. But with the actual firmware SD17 of the drive it is not supported for ReadyNAS (as of actual hardware compatibility list form Netgear).

msinn

Reviving an old thread. I just purchased 3x of these units to upgrade my existing NV+, and noted I've got firmware CC1H and the drives are made in Thailand. Looks like Seagate have not updated firmware for quite a while?

Just chatted with a Seagate rep, and he said that a few initial Reallocated sectors is "normal" (under 100 total). Here is the chat transcript:

I have 3 Seagate ST31500341AS drives I recently purchased (all CC1H firmware) which are showing SMART Reallocated Sectors. ... Jeff W: We can always repalce the drives as long as they are in warranty Me: so the drives should never be reallocating sectors? Jeff W: But I would like to make sure it isn't the raid controller causing the sectors Me: looks like 1 drive has 6, the other has 9, and the 3rd has 0. Jeff W: Under 100 you are fine Me: so a few realloc sectors is normal? Jeff W: yes Jeff W: That is why we add them to the drive Jeff W: as long as you are not near 100 you should be ok ...

Not sure if this is correct or not as the number of realloc sectors he stated (100) seems a bit arbitrary, but it's what Seagate reps are saying.

Anyhow, I came across a Google's study on SMART Reallocated Sectors performed on over 100,000 drives which is sort of interesting as well (see "Conclusion" section of the PDF at http://labs.google.com/papers/disk_failures.pdf):

[Google's] results confirm the findings of previous smaller population studies that suggest that some of the SMART parameters are well-correlated with higher failure probabilities. We find, for example, that after their first scan error, drives are 39 times more likely to fail within 60 days than drives with no such errors. First errors in reallocations, offline reallocations, and probational counts are also strongly correlated to higher failure probabilities. Despite those strong correlations, we find that failure prediction models based on SMART parameters alone are likely to be severely limited in their prediction accuracy, given that a large fraction of our failed drives have shown no SMART error signals whatsoever. This result suggests that SMART models are more useful in predicting trends for large aggregate populations than for individual components. It also suggests that powerful predictive models need to make use of signals beyond those provided by SMART.

I'm not an HD expert, but I'm wondering how much to trust low-volume SMART errors? Are they really conclusive as a measure of drive health (since I don't want to RMA a thousand drives to find one without any SMART errors if it doesn't really matter)? ugh...

I have spent the last two weeks trying to figure out why my Pro 6 freezes the network intermittntly wen I play a video via DLNA.
Blaming DLNA, AFP and all sorts of things that look possible causes.
But searching around the forum I find this thread. I recently fitted a new 1.5Tb Seagate drive and since then the problems have started. But.....

I have Model: ST31500341AS
Firmware: SD37

So the problem fir certain persists in SD37.

I have one more disk of this tpe to fit yet. What the hell do I do now?

Further to my above post.
When my Pro 6 freezes, I get the following in the syslog:

Nov 21 00:00:17 MainStore kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 21 00:00:17 MainStore kernel: ata4.00: failed command: FLUSH CACHE EXT
Nov 21 00:00:17 MainStore kernel: ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Nov 21 00:00:17 MainStore kernel: res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 21 00:00:17 MainStore kernel: ata4.00: status: { DRDY }
Nov 21 00:00:17 MainStore kernel: ata4: hard resetting link
Nov 21 00:00:17 MainStore kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Nov 21 00:00:17 MainStore kernel: ata4.00: configured for UDMA/33
Nov 21 00:00:17 MainStore kernel: ata4.00: retrying FLUSH 0xea Emask 0x4
Nov 21 00:00:17 MainStore kernel: ata4.00: device reported invalid CHS sector 0
Nov 21 00:00:17 MainStore kernel: ata4: EH complete
Nov 21 00:22:53 MainStore kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 21 00:22:53 MainStore kernel: ata4.00: failed command: FLUSH CACHE EXT
Nov 21 00:22:53 MainStore kernel: ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Nov 21 00:22:53 MainStore kernel: res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 21 00:22:53 MainStore kernel: ata4.00: status: { DRDY }
Nov 21 00:22:53 MainStore kernel: ata4: hard resetting link
Nov 21 00:22:53 MainStore kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Nov 21 00:22:53 MainStore kernel: ata4.00: configured for UDMA/33
Nov 21 00:22:53 MainStore kernel: ata4.00: retrying FLUSH 0xea Emask 0x4
Nov 21 00:22:53 MainStore kernel: ata4.00: device reported invalid CHS sector 0
Nov 21 00:22:53 MainStore kernel: ata4: EH complete

I have disabled write-cache to see if this fixes the problem but dont see what this has to do with a read-mode video stream.

With write-cache turned off, I dont get the messages anymore. But the Pro 6 continues to drop off the network every now and then when streaming a movie via mindlna.
But I also see the problem when copying OR reading large files to and from the NAS.