Sa-Sa-Sushi:
With respect to smartmontools, smartctl, etc. and DriveDX, if you open up the DriveDX application and enter the folder DriveDX.app->Contents->Resources you will find an HTML file named "acknowledgements.html" along with smartctl. You can open the acknowledgements.html file and it will tell that it's essentially using smartctl to obtain SMART data. Because it's GNU licensed, I believe he's required to put that in the package.
The external drive drivers are just some more freeware that the guy is using to allow SMART access to external drives, provided they support it. By the way, if you update MacOS you may find you need to re-install the drivers (not a big deal, just thought I'd put that out there for anyone interested). The external SMART drivers will also work with other stuff as well, FWIW
The writers of DriveDX are basically re-interpreting the output from smartctl and putting it into a more user friendly interface. If the writers of smartmontools have no problems with that then I see no reason why anyone else should either.
Killerovsky:
If you want to detect "fault cable" - keep an eye on SMART attribute #199 "CRC Error Count" and #188 "Command Timeout". There also some other SMART attribute that could report "fault cables" but they are vary for different drive models.
If you want detect data corruption occurring between the drive and the system - keep an eye on following SMART attributes: #1 "Read Error Rate", #13 Soft Read Error Rate, #199 "CRC Error Count", #204 "Soft ECC Correction", etc. Note: relevant SMART attributes may vary for different drive models.
Another effective way to "detect data corruption occurring between the drive and the system" is keep an eye on system I/O error count - this is not part of SMART but some tools like DriveDx or SMART Reporter have such feature (system I/O Errors monitoring).
You cannot detect problems outside of the hard drive using SMART monitoring. Once a SMART session is started it's handled entirely by the drive controller and it's only testing components inside the drive. During and at the completion of tests data may be made available to an interpreter, but nothing outside the drive will be tested.
You need to keep in mind that a hard drive is actually a subsystem unto itself. Cable faults, particularly to/from the drive heads can become intermittent leading to CRC failures. Likewise, the amplifiers feeding/receiving data to the drive heads can start to fail like any other amplifier and induce incorrect read and write data. There are a myriad of failures that can occur inside the drive/controller assemblies.
The function of the controller is to interpret commands sent to it by the system, respond to them, and then send the appropriate data back to the system. Once the data going to the system is sent out the controller's I/O port, it's the system's problem, not the drive's. If SMART was interpreting I/O errors in I/O cables outside the drive it would be embedding false errors (i.e. errors not caused by the drive) into the SMART data, and people would be replacing perfectly good drives when a cable is the problem. I don't think drive manufacturer's would think too much of that. You cannot expect SMART to record problems that have nothing to do with the drive itself.
The link FritzPeter put up about about the guy using DriveDX and getting bad results, then updating it and getting good results highlights one of the problems with SMART. Anyone that's worked in the electronics industry, particularly in the computer industry is well aware of one simple fact: Designers are constantly changing things. In some cases it's because one chip manufacturer may offer bulk quantities of chips for a lower price, in others it may be because of scarcity or even discontinuation of a product. In any case, the design and implementation often needs to be tweaked and modified to accommodate such changes. The changes, albeit often minor often require re-writing or modifying the controller code, which in turn, depending on the severity of the changes, may require modification of SMART software.
If you've ever visited an actual data recovery facility, they typically recover data from a bad drive using a "donor" drive. They will make a point of matching the controller and firmware revisions with those of the actual drive housing because they're well aware of the types of modifications manufacturers make, even though the model numbers may be identical.
Third party SMART software is thus always playing a proverbial game of "catch up" with the manufacturers. That doesn't mean that smartctl or DriveDX are "bad" programs or poorly written, it simply means that drive manufactures can do as they wish - they're under no obligation to report their changes to these people.
When testing bad drives, I've found that if I'm using Scannerz and it fails a drive, if I send the report, the log file, and now the diagnostics report confirming the problem to a manufacturer, they never question it. They just send me the RMA and shipping information. The few times I've reported SMART related problems, I've typically been introduced to the following "game:"
- Remove the drive from the unit
- Put the drive in a Windows system
- Download their own proprietary software
- Run their specified tests on the unit
- Send the report on the drive to them to evaluate
- Wait for them to respond
You may be surprised how little support these guys have for Mac's, even though they advertise their units as "fully Mac compatible." This obviously wouldn't apply in the case where a drive was flat out dead, but in cases where there are signs of degradation, don't expect manufacturers to accept third party SMART data as viable.
What do you think about DiskWarrior?
Disk Warrior is a totally different type of tool DriveDX is HD only, Scannerz is Drive/System testing, and Disk Warrior is file recovery. Disk Warrior is most notable for being able to recover data from a drive where the actual index files have become corrupt. It's generally very good at it, but personally I haven't encountered that problem in years.
