Hard disk geeks - here's one for ya: SMART

16k_zx81

Well-Known Member
Reaction score
54
Location
South Australia
DV6 with 650GB SATA internal.

On boot, black screen with white lettering "SMART failure. Back up your data"

Mount disk on another machine, run CrystaldiskInfo. No SMART issue ("Good"), but Windows detects the disk as bad and asks to do a backup.

:confused:

I dont get this at all. Why would it trigger SMART failure on HP and in Windows, but CDI cant see any issue?

- yes I was looking at the correct disk, in case you were wondering :P

:confused:

[edit]

??

http://prntscr.com/j7qhu

[edit 2]

I use CDI a lot and am a bit concerned about this. Have emailed the author. If I get a response will post here.

Jim
 
Last edited:
Since it's a Seagate Momentus drive, I'd suggest using the company's SeaTools (for DOS or Windows) Diagnostic, and see what it says. If you need to RMA the drive, Seagate requires you to use this tool anyway, and to include a print-out of the results with the returned drive.
 
I dont get this at all. Why would it trigger SMART failure on HP and in Windows, but CDI cant see any issue?

SMART data can be read from the drive by various applications. However, the attributes and raw values are not necessarily standardized across the industry, and the meaning of this data can be subject to drive/manufacturer interpretation. This is one of the things that can make SMART data so unreliable for determining drive health. In my experience, you get much more validity from the manufacturer's tools (Seatools as mentioned above), and by running the drives self tests (short and extended).

The last time I used Saetools for DOS, it generated a code for the RMA form when it failed the test.
 
Cool that makes sense

Its really iffy though having such different reports

Just for gits and shiggles I run HDDTUNE surface scan on it. 0% damage.

Wont run Seatools on this occasion as its not RMA and will just replace outright.

.
 
Hey 16k,

To me it looks like CDI is working better than HD Tune in your picture. CDI did pick up the "End-to-End Error" ID attribute when HDT reported it as an unknown attribute. Perhaps that is why HDT(131) and CDI(83) show different values? Is CDI enumerating the value correctly because the error is identified?
To CDI's defense, the reason it doesn't report an error is because the threshold is 97 and the error is at 83... which is the standardization issue SilverLeaf mentioned. Concerning indeed.

I had to look up "End-to-End error"

This attribute is a part of Hewlett-Packard's SMART IV technology, as well as part of other vendors' IO Error Detection and Correction schemas, and it contains a count of parity errors which occur in the data path to the media via the drive's cache RAM.[19]
http://en.wikipedia.org/wiki/S.M.A.R.T.

I had a good read at HP. Although Wikipedia marks the End-to-End error as a "Potential indicators of imminent electromechanical failure" - according to HP's SMART IV datasheet block diagram the problem could just as easily be the Interface logic, or the SDRAM Data Buffer. That would explain why a surface scan passes. Because the error hasn't occurred *that much* I wouldn't be surprised to see the drive pass a set of surface tests just to fail the next set. The good news is that drive will notify the OS in real-time and resend the data to attempt a new read or write... which seems to be happening for that drive at only 83 (or 131 HD Tune) errors.

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01159621/c01159621.pdf
Starting in late 2007, new HP business desktops and Workstations will begin incorporating SMART IV technology in hard drives. While the current versions of SMART do a good job monitoring the data on the hard drive media, the ever increasing emphasis on reliability and quality led Hewlett-Packard and hard drive manufacturers to better ensure that the data flow from host interface to media and media to host interface is not compromised. This is done by adding a parity code to every 512 byte block in the data path of the hard drive's Cache RAM. This parity checking, which is called SMART IV by HP, provides more complete error detection coverage of the entire data path between the host and the hard drive. In the hard drive industry, SMART IV is also known as End-to-End Error Detection.

How SMART IV works

• SMART IV uses a 2 byte parity code to enable it to better detect if data is valid during transfers to and from the data buffer of the hard drive. If the parity data does not match after transferring through the cache RAM data buffer, then depending upon the command, the drive can do a background retry to get data again or report the error message to the host.
• During a disk read, a 2 byte parity code is generated after the data is transferred from the disk. After transfer from the data buffer to the drive interface, the parity data is checked (see Figure 1).
• During a disk write, a 2 byte parity code is generated and appended to the data going into the data buffer. The parity code is checked before it goes into the data buffer and before it is written to the disk (see Figure 2).
• If an error is detected by the drive and the data cannot be retrieved or sent without failure, a protocol is in place to notify the host operating system of the error. The host operating system can then decide to resend the command or notify the user that a data error may have occurred.
If errors are detected, a SMART attribute called End-to-End Error Detection Count is updated. If the SMART threshold is crossed, an imminent failure error message is reported to the user either through Client Management Software that has been installed in the operating system or by the HP BIOS on the next reboot.
 
To me it looks like CDI is working better than HD Tune in your picture. CDI did pick up the "End-to-End Error" ID attribute when HDT reported it as an unknown attribute. Perhaps that is why HDT(131) and CDI(83) show different values? Is CDI enumerating the value correctly because the error is identified?

The HDT and CDI values are the same
131 (base 10) = 83 (base 16) :eek:
 
Hey 16k,

To me it looks like CDI is working better than HD Tune in your picture. CDI did pick up the "End-to-End Error" ID attribute when HDT reported it as an unknown attribute. Perhaps that is why HDT(131) and CDI(83) show different values? Is CDI enumerating the value correctly because the error is identified?
To CDI's defense, the reason it doesn't report an error is because the threshold is 97 and the error is at 83... which is the standardization issue SilverLeaf mentioned. Concerning indeed.

I had to look up "End-to-End error"



I had a good read at HP. Although Wikipedia marks the End-to-End error as a "Potential indicators of imminent electromechanical failure" - according to HP's SMART IV datasheet block diagram the problem could just as easily be the Interface logic, or the SDRAM Data Buffer. That would explain why a surface scan passes. Because the error hasn't occurred *that much* I wouldn't be surprised to see the drive pass a set of surface tests just to fail the next set. The good news is that drive will notify the OS in real-time and resend the data to attempt a new read or write... which seems to be happening for that drive at only 83 (or 131 HD Tune) errors.

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01159621/c01159621.pdf

Awesome contribution. Thats really informative. Thankyou!

(would +rep but Im not allowed to pass to you again) :rolleyes:
 
Yup, I don't put value into SMART..and I don't trust other HDD diags. I've mentioned this in a few threads...the time it takes to go run other diags...costing you time that you can put to more productive billing. For that time, if a HDD is suspect (our experience and seat of the pants should be reliable for this)...clone to a new HDD if you suspect anything. Client gets a better end result for that same amount of money you bill them...a computer with a new HDD that will perform better and live longer.
 
Back
Top