Refer to the above image, you can see the two yellow lines. But they are not the main problem.

The Raw Read Error Rate and Seek Error Rate are extremely high, do I need to worry about that??

How ever refer to the reply on seagate forum, there should be nothing to worry, because my current seek error rate is just 77, not as poor as the situation stated on the forum.

However, I think that I should buy one more 2TB for backup, but what I concerned is the price. Because I’ve already bought this is a little bit expensive.

I am still using firmware CC34 not new firmware CC35, but I don’t have the problem which most people complained about, may be no upgrade is required.

Re: New Maxtor STM3500320AS (500GB) S.M.A.R.T. – Problem

02-01-2009 06:10 PM

I believe that the raw 48-bit Seek Error Rate attribute is encoded as follows:topmost 16 bits = total number of seek errors
bottom 32 bits = total number of seeksTherefore the Seek Error Rate is equal to …

(total number of seek errors) / (total number of seeks)

In your case …

4299089076 = 0x0001003EE4B4

… so your drive has experienced 1 seek error in 4,121,780 (= 0x3EE4B4) seeks.

Seagate drives appear to begin life with an assumed SER of 1 error in 1 million seeks. This equates to a normalised attribute value of 60. If the drive’s SER improves, then this value increases, otherwise it falls.

The normalised attribute appears to follow a logarithmic pattern:

90% = < 1 error per 1000 million seeks
80% = < 1 error per 100 million
70% = < 1 error per 10 million
60% = < 1 error per million
50% = 10 errors per million
40% = 100 errors per million
30% = 1000 errors per million

Your current value is 66 which is better than 1 error per million but worse than 1 error per 10 million.

The Raw Read Error Rate appears to reflect a sector count rather than an error rate, although I’m not sure of this as I’ve yet to see a 48-bit raw value with anything other than 0 in the upper 16 bits.

Anyway here are the results of my investigations:

Based on your results, I expect that the lower 28 bits may reflect a sector count, allowing for 268,435,456 reads. The uppermost bits may hold an error count. The cycle is probably repeated for the next block of 256K reads, and the normalised value is probably incremented or decremented depending on the new error count. However, this is only a guess.

Your current normalised value is 117, which probably suggests that the drive’s read performance is improving.

If we use your statistics, then we have 300,000 sectors being read every 6 seconds. This amounts to a transfer rate of 25MB/sec.

Similary, there are 230 seeks every 6 seconds, ie 26ms per seek.

If each seek corresponds to a switch between tracks, then there are approximately 652KB per track, at least in the zone where your testing is being done.