[opensuse] Interpretation please
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry. *sda* SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 130073028 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 1006 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 4341556312 9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 12166 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 933 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 094 000 Old_age Always - 3228 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 053 045 Old_age Always - 28 (Min/Max 17/29) 194 Temperature_Celsius 0x0022 028 047 000 Old_age Always - 28 (0 10 0 0 0) 195 Hardware_ECC_Recovered 0x001a 042 027 000 Old_age Always - 130073028 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 1 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 5553392728641 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 2804485771 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 33088652 SMART Error Log Version: 1 No Errors Logged *sdb* SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 112 099 006 Pre-fail Always - 45408425 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 863 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 067 060 030 Pre-fail Always - 17202052028 9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 11380 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 863 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 099 000 Old_age Always - 2 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 052 045 Old_age Always - 28 (Min/Max 18/29) 194 Temperature_Celsius 0x0022 028 048 000 Old_age Always - 28 (0 11 0 0 0) 195 Hardware_ECC_Recovered 0x001a 031 017 000 Old_age Always - 45408425 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 106661217842669 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 1596433859 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 280736335 SMART Error Log Version: 1 No Errors Logged Thanks in advance. BTW, both drives are Seagate Barracuda 1TB SATA 3 and are 2 years old. BC -- Using openSUSE 13.1, KDE 4.13.3 & kernel 3.16.1-7 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Aug 31, 2014 at 7:33 AM, Basil Chupin <blchupin@iinet.net.au> wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry.
The usefulness and predictive ability of S.M.A.R.T. can be argued, but from the information you provided both drives seem to be operating normally. It looks like the temperature of the drives did approach 50C at one point, so I'd check the drives under full load to make sure they are being cooled adequately. Brandon Vincent -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-08-31 16:33, Basil Chupin wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry.
Nope. But make sure you run the long test, then look at the results again. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Some might regard this as "ok", but I wouldn't. The Raw Read Error Rate is non-zero, heck over 130billion, seek error rate doesn't look good, Total blocks read is less than 3X the correctable read error rate. Going through a correction for 1/3rd of your blocks seems, AT LEAST, like it would be slowing things down, and would seem risky. On a good disk those error rates would be at or near zero. But your disk is falling back to EDD correction over 1/3rd the time now. That doesn't sound good to me... but maybe I'm more paranoid. My motto was at first sign of disk corruption (even correctable), replace the drive. You don't want to wait till it is "uncorrectable", trust me. Basil Chupin wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry.
*sda*
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 130073028 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 1006 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 4341556312 9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 12166 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 933 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 094 000 Old_age Always - 3228 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 053 045 Old_age Always - 28 (Min/Max 17/29) 194 Temperature_Celsius 0x0022 028 047 000 Old_age Always - 28 (0 10 0 0 0) 195 Hardware_ECC_Recovered 0x001a 042 027 000 Old_age Always - 130073028 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 1 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 5553392728641 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 2804485771 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 33088652
SMART Error Log Version: 1 No Errors Logged
*sdb*
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 112 099 006 Pre-fail Always - 45408425 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 863 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 067 060 030 Pre-fail Always - 17202052028 9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 11380 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 863 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 099 000 Old_age Always - 2 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 052 045 Old_age Always - 28 (Min/Max 18/29) 194 Temperature_Celsius 0x0022 028 048 000 Old_age Always - 28 (0 11 0 0 0) 195 Hardware_ECC_Recovered 0x001a 031 017 000 Old_age Always - 45408425 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 106661217842669 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 1596433859 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 280736335
SMART Error Log Version: 1 No Errors Logged
Thanks in advance.
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
Continuing with this top posting, because Linda started it.... ;-) Is it possible, Linda, you have misinterpret the readings? See: http://www.linuxjournal.com/node/6983/print 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: the disk's temperature in Celsius (29), plus its lifetime minimum (23) and maximum (33) values. The format of the raw data is vendor-specific and not specified by any standard. To track disk reliability, the disk's firmware converts the raw value to a normalized value ranging from 1 to 253. If 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). For example, disk spin-up time (ID #3) is a prefailure Attribute. If this (or any other prefail Attribute) fails, disk failure is predicted in less than 24 hours. 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. The number you want is in the VALUE column. On 9/1/2014 5:17 PM, Linda Walsh wrote:
Some might regard this as "ok", but I wouldn't.
The Raw Read Error Rate is non-zero, heck over 130billion,
seek error rate doesn't look good,
Total blocks read is less than 3X the correctable read error rate.
Going through a correction for 1/3rd of your blocks seems, AT LEAST, like it would be slowing things down, and would seem risky.
On a good disk those error rates would be at or near zero. But your disk is falling back to EDD correction over 1/3rd the time now. That doesn't sound good to me... but maybe I'm more paranoid.
My motto was at first sign of disk corruption (even correctable), replace the drive. You don't want to wait till it is "uncorrectable", trust me.
Basil Chupin wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry.
*sda*
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 130073028 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 1006 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 4341556312 9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 12166 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 933 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 094 000 Old_age Always - 3228 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 053 045 Old_age Always - 28 (Min/Max 17/29) 194 Temperature_Celsius 0x0022 028 047 000 Old_age Always - 28 (0 10 0 0 0) 195 Hardware_ECC_Recovered 0x001a 042 027 000 Old_age Always - 130073028 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 1 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 5553392728641 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 2804485771 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 33088652
SMART Error Log Version: 1 No Errors Logged
*sdb*
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 112 099 006 Pre-fail Always - 45408425 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 863 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 067 060 030 Pre-fail Always - 17202052028 9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 11380 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 863 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 099 000 Old_age Always - 2 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 052 045 Old_age Always - 28 (Min/Max 18/29) 194 Temperature_Celsius 0x0022 028 048 000 Old_age Always - 28 (0 11 0 0 0) 195 Hardware_ECC_Recovered 0x001a 031 017 000 Old_age Always - 45408425 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 106661217842669 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 1596433859 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 280736335
SMART Error Log Version: 1 No Errors Logged
Thanks in advance.
BTW, both drives are Seagate Barracuda 1TB SATA 3 and are 2 years old.
BC
-- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On Mon, 01 Sep 2014 21:13:26 -0700 Linda Walsh wrote:
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.
Well, this technology has come a long way in 20 years. Here I've been, minding my own business, operating on the background assumption that S.M.A.R.T. _now_ is pretty much what it was back then -- maybe with more 'bells and whistles' accrued over that time. My understanding from when I delved deeply into it (I was working in the storage products industry, btw, in Silicon Valley) was that 'raw read error rate' and 'seek error rate' related to 'cache misses' not actual, physical read errors. My understanding was that these metrics were being used statistically, internally, over long periods of time and across a massive install base by the manufacturers to monitor and improve caching algorithms. In Seagate's own words*: "The idea ... is to predict a failure before it happens. Various attributes are being monitored and measured against certain threshold limits. If any one attribute exceeds a threshold then a general SMART Status test will change from Pass to Fail." and "The individual attributes and threshold values are proprietary and we do not offer a utility that will read out the values." Finally, "As a practical matter, the technology supporting SMART is constantly being improved. Each new design incorporates improvements that increase the accuracy of the SMART prediction. As a matter of policy, Seagate does not publish attributes and thresholds. Therefore, if you wish to test the drive for physical integrity, please use our SeaTools diagnostic software." From a practical standpoint, a 'fail' in lieu of a 'pass' with a drive that remains operational, under warranty, is sufficient to obtain a warranty replacement drive from Seagate. In the OP's specific case, if the attribute 'reallocated sector count' is correct for both drives, they're at zero (0). All things being equal, between that and SMART test 'pass' would give me a fairly high degree of confidence that failure doesn't seem to be imminent. I'd still, as I always do, back up my important data. (*) <http://knowledge.seagate.com/articles/en_US/FAQ/203971en> regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-09-02 06:13, Linda Walsh wrote:
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.
All modern Seagate disks have huge "error rate" values. Means nothing. Or at least, it does not mean what a person would normally think :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-09-02 02:17, Linda Walsh wrote:
Some might regard this as "ok", but I wouldn't.
The Raw Read Error Rate is non-zero, heck over 130billion,
seek error rate doesn't look good,
Not on a Seagate. They are typical values. Some of mine: Telcontar:~ # smartctl -a /dev/sda | grep Error_Rate 1 Raw_Read_Error_Rate 0x000f 119 099 006 Pre-fail Always - 214928042 7 Seek_Error_Rate 0x000f 079 060 030 Pre-fail Always - 100635483 Telcontar:~ # smartctl -a /dev/sdb | grep Error_Rate 1 Raw_Read_Error_Rate 0x000f 114 099 006 Pre-fail Always - 59835741 7 Seek_Error_Rate 0x000f 078 060 030 Pre-fail Always - 82836624 Telcontar:~ # smartctl -a /dev/sdc | grep Error_Rate 1 Raw_Read_Error_Rate 0x000f 114 099 006 Pre-fail Always - 63128408 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 48111013 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/09/14 00:33, Basil Chupin wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry.
[PRUNED] Thanks to all who provided comments on the results I got from running smartctl on my 2 HDDs. I reran the tests again on both drives last night and got a DECREASED reading for one (?two) of the results. Go figure. However, I am replacing both drives this coming weekend to be on the safe side - and will then send the test results to Seagate to get their comments. Depending on what they state, I will either keep the HDDs as backups or "shred" them. BC -- Using openSUSE 13.1, KDE 4.14.0 & kernel 3.16.2-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2014-09-11 at 17:17 +1000, Basil Chupin wrote:
However, I am replacing both drives this coming weekend to be on the safe side - and will then send the test results to Seagate to get their comments. Depending on what they state, I will either keep the HDDs as backups or "shred" them.
AFAIK, there is nothing wrong with them, but they are not new. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQSV70ACgkQtTMYHG2NR9UaggCfb0nMmh9CXPvLX70I46QTN8mr kYoAn0axENzIbLls2azaLLAfoVGYHjnO =e52E -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/09/14 12:17, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2014-09-11 at 17:17 +1000, Basil Chupin wrote:
However, I am replacing both drives this coming weekend to be on the safe side - and will then send the test results to Seagate to get their comments. Depending on what they state, I will either keep the HDDs as backups or "shred" them.
AFAIK, there is nothing wrong with them, but they are not new.
Sorry for not replying before now - but I didn't want to before I had tried out the new HDDs. As I mention in another thread, I collected a couple of new Seagate (Constellation CS 1TB) HDDs last weekend, and earlier today I mounted them, booted with the 13.1 Rescue Disc, and ran 'smartctl -a .....' against each one. Now, these HDDs are "untouched by human hands, and are virgins" :-) - ie, uncontaminated by being formatted, are straight from the factory via the computer shop - and yet the HDDs have readings of- sda : 40,624 Raw_Read_Error_Rate and 73 Seek_Error_Rate sdb: 40,232 Raw_Read_Error_Rate and 105 Seek_Error_Rate Both HDDs show that each was started twice - once at the factory I would assume and then when I started them for the above test. This indicates to me that these figures for Seagates - as I think it was you who suggested this - is normal. However, I will send to Seagate the smartctl tests for the HDDs re which I started this thread to ask them what Seagate think of the figures. BC -- Using openSUSE 13.1, KDE 4.14.0 & kernel 3.16.2-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-09-19 11:19, Basil Chupin wrote:
On 12/09/14 12:17, Carlos E. R. wrote:
Both HDDs show that each was started twice - once at the factory I would assume and then when I started them for the above test.
This indicates to me that these figures for Seagates - as I think it was you who suggested this - is normal.
Indeed. Yes, and yes :-)
However, I will send to Seagate the smartctl tests for the HDDs re which I started this thread to ask them what Seagate think of the figures.
If they answer at all, I mean a human response, not a robot or a flower pot, it would be very interesting to learn about it ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 19/09/14 21:01, Carlos E. R. wrote:
On 2014-09-19 11:19, Basil Chupin wrote:
On 12/09/14 12:17, Carlos E. R. wrote:
Both HDDs show that each was started twice - once at the factory I would assume and then when I started them for the above test.
This indicates to me that these figures for Seagates - as I think it was you who suggested this - is normal. Indeed. Yes, and yes :-)
However, I will send to Seagate the smartctl tests for the HDDs re which I started this thread to ask them what Seagate think of the figures. If they answer at all, I mean a human response, not a robot or a flower pot, it would be very interesting to learn about it ;-)
I received the response from Seagate Support last night and it was that there does not appear to have anything to worry about. But they also suggested that I download the latest SeaTools - which I did - and run tests against each of the HDDs just to confirm S.M.A.R.T.'s results. I haven't done this yet. BC -- Using openSUSE 13.1, KDE 4.14.1 & kernel 3.16.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-09-23 11:18, Basil Chupin wrote:
On 19/09/14 21:01, Carlos E. R. wrote:
However, I will send to Seagate the smartctl tests for the HDDs re which I started this thread to ask them what Seagate think of the figures. If they answer at all, I mean a human response, not a robot or a flower pot, it would be very interesting to learn about it ;-)
I received the response from Seagate Support last night and it was that there does not appear to have anything to worry about.
But they also suggested that I download the latest SeaTools - which I did - and run tests against each of the HDDs just to confirm S.M.A.R.T.'s results. I haven't done this yet.
Ah... they probably have that on the stock copy paste replies. I did have a list of replies to give on a similar job - I just copy pasted them liberally when appropriate ;-) There are two version of Seatools. Both are good. The modern one only runs in Windows. There is another one that they offer as a downloadable ISO, which boots. It is a MsDOS or FreeDOS (I don't remember which) image. It is what you have to use if your machine runs Linux. The only problem it has is that it is incapable of saving or printing the resulting report :-( -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 09/23/2014 01:25 PM, Carlos E. R. wrote:
that it is incapable of saving or printing the resulting report :-(
- need to use camera or phone to take photo ?? regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-09-23 13:13, ellanios82 wrote:
On 09/23/2014 01:25 PM, Carlos E. R. wrote:
that it is incapable of saving or printing the resulting report :-(
- need to use camera or phone to take photo ??
May not be valid in order to return the disk to the manufacturer on warranty. Dunno. They have a very specific protocol for returning disks which you have to follow to the letter. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 09/23/2014 03:47 PM, Carlos E. R. wrote:
May not be valid in order to return the disk to the manufacturer on warranty. Dunno. They have a very specific protocol for returning disks which you have to follow to the letter.
"Time is money|. - BENJAMIN FRANKLIN ___________________ - if one has to jump so high to return . . . maybe best just buy another 'marque' .................. regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-09-23 15:16, ellanios82 wrote:
On 09/23/2014 03:47 PM, Carlos E. R. wrote:
May not be valid in order to return the disk to the manufacturer on warranty. Dunno. They have a very specific protocol for returning disks which you have to follow to the letter.
"Time is money|. - BENJAMIN FRANKLIN ___________________
- if one has to jump so high to return . . . maybe best just buy another 'marque'
Well, time is money indeed. Not following the procedure means that they have to invest more time to process your request. The instructions are detailed to the point of telling you how to package the disk to avoid damage to the unit. If it is damaged in transit to them, and you did not properly protect it, they can very well refuse or charge you the expenses. All that is very sensible. They do provide a testing software that Linux users can use (others only provide a Windows program, or none at all), but being a CD you can not write files. And being MsDOS, it knows nothing about usb sticks. Yes, they should improve this. I don't know if one could build his own test r/w media somehow. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 23/09/2014 15:47, Carlos E. R. a écrit : I don't know if one could build his own test r/w media somehow. they software is very good and saved my life once, reviving a presumed dead disk. jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/23/2014 04:47 PM, Carlos E. R. wrote:
I don't know if one could build his own test r/w media somehow.
apropos of not much : ________________ i do have several hard-disks that have 'crapped-out' and been replaced, over the years : later, have wiped out the partitions, and re-partitioned those old 'crapped-out' hard disks, with 1 or 2 partitions [instead of 4 partitions previously] and used them for once-a-month whole-system back-ups : - some of these re-partitioned those old 'crapped-out' hard disks seem to go on for ever - like 10 years of once-a-month use ? { i dunno ??} .................. regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/09/2014 16:24, ellanios82 a écrit :
- some of these re-partitioned those old 'crapped-out' hard disks seem to go on for ever - like 10 years of once-a-month use ?
{ i dunno ??}
yes. random curve. Some disks do not like to be stopped. A very long time ago, I was a teacher and every September some of the disks didn't start. Sometime, hitting them firmly on the table revived them (probably lubricant problem). but this was a long time ago, not seen this for years. on a n other side, I have seen 3 SCSI Hard drives dead on the same computer., that was unused for some month. other parts also wgere dead, May be a thunderstrike (on not connected machine????) anyway better have three copies :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2014-09-23 at 16:16 +0300, ellanios82 wrote:
_______________________
"Time is money|. - BENJAMIN FRANKLIN ___________________
If you really believe that, i'd suggest you install your own time server -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/23/2014 11:36 PM, Hans Witvliet wrote:
own time server
or, was it Groucho Marx ?? : "plenty of time . . . no money" ........................... regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 01 Sep 2014, Basil Chupin wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry.
As these are Seagates ...
*sda*
1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 130073028
This seems to be normal for those drives.
3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0
That's bogus. *No* rotating rust drive spins up in 0ms ;) But I got the same on the 3T newer Seagate ST31500341AS (the only one not external).
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 1006
ok
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
very good
7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 4341556312
still "typical" for these drives, I think.
9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 12166
definitely ran a bit ;)
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
this is good.
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 933 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
all good
188 Command_Timeout 0x0032 100 094 000 Old_age Always - 3228
not very good, but can't compare (my smartd/smartctl on that box is too old for that disk)
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 053 045 Old_age Always - 28 (Min/Max 17/29) 194 Temperature_Celsius 0x0022 028 047 000 Old_age Always - 28 (0 10 0 0 0)
ok.
195 Hardware_ECC_Recovered 0x001a 042 027 000 Old_age Always - 130073028
That's normal, I think, for those disks.
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
very good.
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 1
This would point to a flaky cable/connection, if it were higher.
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 5553392728641
Typically bogus / smartctl not recent enough. Nothing to worry about though.
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 2804485771 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 33088652
Uh? That much more written that read?
7 Seek_Error_Rate 0x000f 067 060 030 Pre-fail Always - 17202052028
That's a bit high... Compare to the other disk (and each "Power_on_Hours")
9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 11380 [..] Thanks in advance.
BTW, both drives are Seagate Barracuda 1TB SATA 3 and are 2 years old.
sdb might have a mechanical/mounting problem, manifested in those high seek errors... It might be as easy to fix as to loosen the screws, realign the disk horizontally/vertically, and retighten the screws ;) Have an eye on that value, but don't mind yet. But: I've had one newer 3T Seagate (not of Samsung descent, I think) those disks recently, with similar SMART-values jump from such as above to >12k bad sectors (realloced / pending / uncorrectable) overnight. Several 1.5T disks (same age as yours) developed just a few sectors (e.g. 6), nothing dramatic, most Windows users will never notice stuff like that ;) I've had a Laptop to switch out the drive, and it had >1k realloced sectors and the user never noticed (but probably some files may be damaged, but migration went fine, so it hopefully just were some system-files ... -dnh --
Stell mal Exchange-Cluster-Knoten in unterschiedliche Zeitzonen. Das ist lustig. (fuer hiesige Werte von "lustig"). -- J. P. Meier Da lerne ich doch lieber Sendmail. Oder programmiere einen Mailserver in Postscript. -- Arnim Sommer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/09/14 00:08, David Haller wrote:
Hello,
On Mon, 01 Sep 2014, Basil Chupin wrote:
I just ran smartctl on my 2 drives, sda and sdb, with the following results. Could someone please interpret these results and tell me if there is cause for worry. As these are Seagates ...
*sda*
1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 130073028 This seems to be normal for those drives. [pruned]
sdb might have a mechanical/mounting problem, manifested in those high seek errors... It might be as easy to fix as to loosen the screws, realign the disk horizontally/vertically, and retighten the screws ;) Have an eye on that value, but don't mind yet.
But: I've had one newer 3T Seagate (not of Samsung descent, I think) those disks recently, with similar SMART-values jump from such as above to >12k bad sectors (realloced / pending / uncorrectable) overnight. Several 1.5T disks (same age as yours) developed just a few sectors (e.g. 6), nothing dramatic, most Windows users will never notice stuff like that ;) I've had a Laptop to switch out the drive, and it had >1k realloced sectors and the user never noticed (but probably some files may be damaged, but migration went fine, so it hopefully just were some system-files ...
Thanks for the comments, David. See my previous response to Carlos where I mention that the response I got from Seagate Support indicates that I have nothing to worry about but they do suggest that I run their SeaTools to confirm the S.M.A.R.T. results. BC -- Using openSUSE 13.1, KDE 4.14.1 & kernel 3.16.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Basil Chupin -
Brandon Vincent -
Carl Hartung -
Carlos E. R. -
Carlos E. R. -
David Haller -
ellanios82 -
Hans Witvliet -
jdd -
John Andersen -
Linda Walsh