Printable View
Is it normal for the SMART attribute "Raw Read Error Rate" to display more than 0? I've never seen anything above 0 before but on my file server drive I noticed it was at 2 after formatting and moving a bit of data but it's now at 8, it's only been in use for about 3-4 days. I know SMART attributes are different on different drives but I'm a little concerned nonetheless, does this mean the drive is faulty?
Thanks. :)
Definately maybe :)
http://en.wikipedia.org/wiki/S.M.A.R.T.
Not clear cut - as this article shows - and if you Google raw data error rate you get conflicting views. It also depends on how the drive mfr defines the raw data error rate.
More info here:
http://opensource-archive.org/showthread.php?t=105940
It is probably something to monitor, periodically, say daily for another week to see if the count increases - but it is a rate - and that implies errors/unit of time, rather than an absolute value. with some drives a lower count is worse than a high count - just depends on how the mfr reports them and how the SMART tool interprets that drives SMART data.
Probably the best way to determine the drive's health is to use Samsungs drive utility.
http://www.samsung.com/global/busine...ort_HUTIL.html
I'm currently running a backup of everything on the drive and it's just gone up to 9. SMART status is 'PASSED' but I'll run the drive utility again once this backup completes.
Edit: Just refreshed and it's now 10. :(
From a WD drive
From a Samsung driveCode:SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 180 179 021 Pre-fail Always - 5958
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 118
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1415
The drives are in a fileserver (with one partition on each in a RAID1 array) Nothing there is giving me concern (sorry about the formatting Edit - formatting sorted :) )Code:SMART Attributes Data Structure revision number: 16
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 100 100 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 087 087 011 Pre-fail Always - 4780
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 36
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 747
I've just run the drive utility (skipped the full ~6 hour scan but I did run that when I first got the drive) and it passed:
-------------------------------------------------
Test Loop Number : 1/1
-------------------------------------------------
>> READ DMA : Testing... Pass !
>> CHECK S.M.A.R.T. : Testing... Pass !
>> SPIN DOWN / UP : Testing... Pass !
>> SIMPLE SURFACE SCAN : Testing... Pass !
>> WRITE VERIFY : Testing... Pass !
>> RANDOM SURFACE SCAN : Testing... Pass !
>> READ SURFACE SCAN : Testing... Skip !
>> RAM VERIFY TEST : Testing... Pass !
>> MULTIPLE READ TEST : Testing... Pass !
Service Code => SJ25 : Test OK.
Total Elapsed Time : 00:01:58
Test was completed.
=================================================
What are the SMART attributes on your Samsungs?
Edit: You answered my question before I posted!! :laugh:
Even though the test passed I'm still a little concerned about that non-0 value, and I've never seen it on any of my other drives.
Is that the raw_value or the value field (200 and 100 on the drive attributes I posted)
It's the raw value. And worryingly it's now at 11.
What are the other fields (value, worst and thresh)?
Value=100, Worst=100, Thresh=51.
Same as my Samsung drive. Probably something to be a little uneasy about, but not panic worthy. Defintely a case of watch and wait - but if the drive isn't in a RAID array, I'd be reviewing my backup strategy, remembering that catastrophic failure is unlikely (though not impossible) - but if the count continues increasing then I would start getting more concerned.
It's not RAIDed but I make regular backups to another drive. When would you consider RMAing the drive? I've contacted Samsung who replied quickly saying basically what you've said, SMART data is hard to interpret, run some tests, keep an eye on the drive and consider an RMA if the value keeps increasing. I might email Scan and see what they say but I don't want to RMA if there's nothing wrong and considering it passes the drive utility they'll probably just return it.
No - not yet - but I would keep an eye on it.
Thanks I will do, but what should I look out for, a change in the 'Vaule' field or something? Also any idea if this can mean actual filesystem data loss or is it still corrected?
Changes in raw_value. These are raw reads, so the decoding and ECC should take care of them. You if you are running logwatch, you should get an abstract of kernel messages that will show read/write data errors to and from the drive. (or look at the messages log - possibly in /var/log or wherever your distro writes its log files.)
Interesting thread here:
http://bbs.archlinux.org/viewtopic.php?id=97773
It's still at 11 so I gather it only rises under load, which makes sense given the attribute name. I've left logging as defaults, any idea what log I should be looking in and what text I should be looking for? I'm guessing /var/log/messages and searching warn, doing that I found a few non-related warnings, mainly something about the ntp daemon.
Thanks for all your help lately BTW! :)
Edit: running fsck took it up to 13 so I'm guessing it's going to keep rising when the disk is being read.
I'm not sure if it's related but the system just failed to boot with the following on screen:
And I had my head next to the system and I could hear a series of high-pitched beeps, there is no PC speaker connected but maybe the speaker circuit was still emitting noise? I pressed the reset button and it booted fine, nothing changed on SMART either.Quote:
...
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
I was in the PC to check voltages which all seemed good (excellent in fact) and while I was only checking to 2 DP on a multimeter there were no digits going up-down which would indicate big ripple, 120mv is the 12v spec so that should show up in 2 DP. No, it's no PSU bench test but it's about the best I can do with what I have. I'll try to get round to running a full scan in that system and take the drive out and see if I can get the error count to rise with fsck on another system.
Big Fat WarningQuote:
Originally Posted by peterb
HUTIL is obsolete and has been known to give false readings with recent generations of Samsung drives (F1 and later). Use ESTool instead.
Samsung should really make this clearer, particularly as the F1 is still listed as a target model for HUTIL.
Thanks, yeah I did use estool.
Right. I'm afraid I can only test on 1 of my HD203WI drives because the others are considered SCSI devices and don't pass on SMART data.
320GB F1: 6
1TB F1: 0
2TB F3: 361
WD Lifeguard passes basic test, sees nothing wrong with the SMART data. I'm running an extended test now to see what happens.
Thanks very much, an extended test takes about 6 hours you know but I think you can still use the drive while it's running.
Edit: sorry I misread that post, so your F3 has a raw value of 361? That's a HUGE relief!!! Thanks again mate! Morale of the story - don't let raw SMART values worry you!
It must be calculated in a different way on the new F3 drives.
I've only owned that 2TB for maybe a month, whilst the 1TB and 320GB are well over a year old. Just wish I could check all of my 2TB drives, would be interesting to compare. Ah well :)
I thought SMART was meant to be standardised? Or MFRs should at least release details on how attributes are actually measured. I think Seagate drives have the raw value for that attribute numbering in the thousands but I was concerned mainly because it was a small number and climbing.
To quote Wikipedia:
So I guess whilst the categories are standardised, the scores aren't. Somehow, I suspect this value will keep climbing forever - whether that's because it's more sensitively tuned in some way, or because it's completely borked, I have no idea :confused:Quote:
As manufacturers do not necessarily agree on precise attribute definitions and measurement units, the following list of attributes should be regarded as a general guide only.
My Samsungs SMART readings as reported by Everest Ultimate:
SAMSUNG HD103UJ (F1 1000GB - media storage)
ID Attribute Description Threshold Value Worst Data Status
01 Raw Read Error Rate 51 100 100 0 OK: Value is normal
03 Spinup Time 11 82 82 6150 OK: Value is normal
04 Start/Stop Count 0 99 99 1038 OK: Always passes
05 Reallocated Sector Count 10 100 100 0 OK: Value is normal
07 Seek Error Rate 51 253 253 0 OK: Value is normal
08 Seek Time Performance 15 100 100 0 OK: Value is normal
09 Power-On Time Count 0 100 100 1878 OK: Always passes
0A Spinup Retry Count 51 100 100 0 OK: Value is normal
0B Calibration Retry Count 0 100 100 0 OK: Always passes
0C Power Cycle Count 0 99 99 722 OK: Always passes
0D Soft Read Error Rate 0 100 100 0 OK: Always passes
B7 <vendor-specific> 0 100 100 0 OK: Always passes
B8 End-to-End Error 99 100 100 0 OK: Value is normal
BB Reported Uncorrectable Errors 0 100 100 0 OK: Always passes
BC Command Timeout 0 100 100 0 OK: Always passes
BE Airflow Temperature 0 68 56 538837024 OK: Always passes
C2 Temperature 0 62 54 639500326 OK: Always passes
C3 Hardware ECC Recovered 0 100 100 28456 OK: Always passes
C4 Reallocation Event Count 0 100 100 0 OK: Always passes
C5 Current Pending Sector Count 0 100 100 0 OK: Always passes
C6 Offline Uncorrectable Sector Count 0 100 100 0 OK: Always passes
C7 Ultra ATA CRC Error Rate 0 100 100 0 OK: Always passes
C8 Write Error Rate 0 100 100 0 OK: Always passes
C9 Soft Read Error Rate 0 253 253 0 OK: Always passes
SAMSUNG HD502HJ (F3, 500GB - OS, games and apps)
ID Attribute Description Threshold Value Worst Data Status
01 Raw Read Error Rate 51 100 100 0 OK: Value is normal
02 Throughput Performance 0 252 252 0 OK: Always passes
03 Spinup Time 25 84 82 5099 OK: Value is normal
04 Start/Stop Count 0 100 100 368 OK: Always passes
05 Reallocated Sector Count 10 252 252 0 OK: Value is normal
07 Seek Error Rate 51 252 252 0 OK: Value is normal
08 Seek Time Performance 15 252 252 0 OK: Value is normal
09 Power-On Time Count 0 100 100 1054 OK: Always passes
0A Spinup Retry Count 51 252 252 0 OK: Value is normal
0B Calibration Retry Count 0 252 252 0 OK: Always passes
0C Power Cycle Count 0 100 100 369 OK: Always passes
BF Mechanical Shock 0 100 100 1 OK: Always passes
C0 Power-Off Retract Count 0 252 252 0 OK: Always passes
C2 Temperature 0 59 52 7, 41 OK: Always passes
C3 Hardware ECC Recovered 0 100 100 0 OK: Always passes
C4 Reallocation Event Count 0 252 252 0 OK: Always passes
C5 Current Pending Sector Count 0 252 252 0 OK: Always passes
C6 Offline Uncorrectable Sector Count 0 252 252 0 OK: Always passes
C7 Ultra ATA CRC Error Rate 0 200 200 0 OK: Always passes
C8 Write Error Rate 0 100 100 2 OK: Always passes
DF Load/Unload Retry Count 0 252 252 0 OK: Always passes
E1 Load/Unload Cycle Count 0 100 100 369 OK: Always passes
Be wary of the limitations of a digital multimenter. It is unlikely that it would register ripple on the PSU lines - you need a 'scope to see that - and just because it measures to a precision of 2dp - doesn't mean that it is accurate to 2dp - you need to read the specs of the multimeter carefully.Quote:
Originally Posted by watercooled
As for the boot problem - if the speaker is disconnected, it is unlikely that the speaker ccts are generating the beeps - but it could have been noise from the PSU or the drive.
There is some information on the parsing ELF status message here
http://forums.fedoraforum.org/showthread.php?t=200456
and here
http://www.linuxjournal.com/article/1060
and an introduction to ELF here
http://cs.mipt.ru/docs/comp/eng/os/l...f-howto-1.html
Again, I can't explain why it might of hung at that point.
Why did you run fsck?
I understand you can't rely on a multimeter to detect ripple but I've observed digits changing when substantial ripple is present, and since all digits were static I'd say ripple is likely to be low.
I haven't heard those beeps before or since, not that pattern at least which sounded to rhythmic for average electronics whine.
I originally ran fsck after messing with partitions, specifically removing the 5% reserved root space from the data partition, after which I noticed an increase in the value. Trying it again raised the value again so I gathered the value increase came from reading data from the disk.
That message always appears on boot but on that occasion it was where the boot hung for whatever reason.
Full test successfully completed after 6 hours, no issues found :)
/me breathes sigh of relief
I think the problem now is that you have lost confidence in the drive - and even if it was RMAd and returned with no fault found - you'd still be suspicious.
So, either take a chance and RMA it with the evidence you have so far, and hope that the retailer agrees with you and replaces it - but be prepared to buy a new one anyway if that one does come back with No fault found, and then just put it in a caddy for non-critical stuff.
I had a new drive fail recently - part of a sof raid - and that drive kept on throwing errors (WD). I assume that it was damaged in transit (very badly packed) so that will be RMA'd shortly - but that is the only instance in quite a long time that I have had a brand new drive fail.
(And before you ask - no, I don't have the SMART data to hand :) - but IIRC it showed high sector remapping - and indication of platter damage on a new drive) But the errors showed up in mdadm and in the kernel message log.
Weird. Drive is a Samsung F3 500gb (HD502HJ).
1. 3 days ago Raw Read Error Rate = 0
2. Yesterday bad sectors found when scanning with chkdsk. Raw Read Error Rate = 19
3. Running estool found a bad sector (marked by chkdsk) and it recommended a low level format
4. After formatting, estool itself declared the drive to be error free
5. Scanning with chkdsk now finds no bad sectors. Raw Read Error Rate = 20
I'm guessing that if it passes estool after a low level format, there is no grounds for warranty replacement.
Could the error simply be generated by data stored in a corrupt manner as a result of crash/reboot etc? It would explain why a low level format finds nothing wrong.
I'm not too suspicious of the drive now after other replies indicating positive read error rate values, but I believe Scan charge you if they don't find a fault so I'd be hesitant to send it off if I wasn't sure it was faulty. I may ask around to see if others with F3s also have this issue for more reassurance though.
Following the low level format and having filled the drive up again, my Raw Read Error Rate has not increased and all tests report healthy.
Scan issued an RMA, but as this is a download/backup drive I'm going to keep it for now.
I thought I was having the only issue with this drive. I got this error message when I first installed the drive.
can't put full links since I'm new, but put this into your web browser to view pic
i45.tinypic.com/ml0bkl.png
I RMA'ed it to Samsung (took about 1 month to get a replacement which they gave me a refurb with different serial #) and it still shows the same error when I first put it in. I ran the WD Lifeguard extended which passed.
Not sure if this drive was designed differently that Windows 7 thinks its going bad, or if I'm just unlucky twice in a row.
I don't think that's the same as what I'm experiencing but I'm not using it with Windows so I'm not sure. Use Samsung's ESTool, not WD's tools for a Samsung drive though and see if that finds anything.
Will report back results tonight from ESTool
Just thought I'd post an update. Since my low level format one month ago the Raw Read Error Rate has not increased.
Thanks, I might give that a try myself. :)
Thanks, yeah I did use estool.