John Andersen wrote:
Continuing with this top posting, because Linda started it.... ;-)
The reason I did it was multifold. 1) It was reference data, not pre-conversation data. 2) My statement stood on it's own, without needing previous conversation. 3) I am uncomfortable posting AFTER a large wall of uninterrupted text, but I didn't know what data was important and what was not enough to comment between the lines. So I wanted to leave it as an appendix .. reference material that someone could look at if they wanted the actual data. Of course, many conversations are like that with actual words and quotes being of possible use in an appendix, but rarely do you find a complete appendix or quotes and opinions of others at the front of a writing -- they usually are placed at the end in appendices or such for reference. Note: my explaining the above reasons should in no way be meant to imply that you replying the the same way was wrong. Similar reasons may apply. I just thought I would elucidate my (unconscious) reasons for doing so. It's partly stylistic, and in this case, an interactive placement as I'm doing more so now, didn't seem appropriate.
Is it possible, Linda, you have misinterpret the readings? See: http://www.linuxjournal.com/node/6983/print
oh contrare!
Each Attribute has a six-byte raw value (RAW_VALUE) and a one-byte normalized value (VALUE). In this case,
the raw value stores three temperatures: .... If you were referring to this: regarding the manufacturers assessment of
^^^^^^^^^^^ In this case, refers to the previous paragraph where they are talking about disk temperatures. That I.e. ALL of the raw values don't refer to temperatures. the seriousness of the threshold having been exceeded (# gone under in this case):
Of this normalized value is less than or equal to the threshold (THRESH), the Attribute is said to have failed, as indicated in the WHEN_FAILED column. The column is empty because none of these Attributes has failed. The lowest (WORST) normalized value also is shown; it is the smallest value attained since SMART was enabled on the disk. The TYPE of the Attribute indicates if Attribute failure means the device has reached the end of its design life (Old_age) or it's an impending disk failure (Pre-fail).
That 130billion number is not the count of raw read errors. Its a combination of temperature, plus lifetime min and maximum values of temperature, and most of all it is VENDOR SPECIFIC.
Nope... It really is the raw error read rate... It matches up exactly with the Hardware ECC correction rate. All of the raw errors are currently being corrected by ECC. When they aren't, you'll start seeing sector remapping, which is when you start to really notice disk slowdowns --- they prevent contiguous reads. I don't know how long one can use ECC to get by with, BUT I've always been told it's the first step towards an unreadable sector that gets remapped. He did want to know my interpretation... Not if I agree with everyone. Obviously, I'm 1 vote among many and I admit to being more paranoid than most w/disk issues. (running RAID10 and daily backups and snapshots of /home)...and I still worry that 2 bad disks can kill an array. C'est la vie. Look at AGE of the disks... in hours... 12166. That's equivalent to 6 years @ 8hours/day. (work week). If the disks have been kept cool. If they are enterprise and not consumer drives, if they are kept at constant speed -- not on/off, 3-5 years is replacement guideline. Hitachi's enterprise drives are only warranted for 5 years, most are 3 years. The drive is probably out of warranty, but maybe not. I don't think he's going to lose data in the next week, BUT I'd trade off that risk with having backups and/or redundancy. If neither, I'd think about replacing sooner rather than later. Ooops... missed the bit at the bottom about them being 2 years old. I'd still keep backups.. But I would likely expect 3 years out of them. Backups are a good thing...
BTW, both drives are Seagate Barracuda 1TB SATA 3 and are 2 years old.
BC
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org