#!/bin/bash
    
    
    smartctl -a /dev/sda > /root/smartStates
    grep Reallocated_Sector_Ct /root/smartStates > /root/stats
    grep Current_Pending_Sector /root/smartStates >> /root/stats
    grep Offline_Uncorrectable /root/smartStates >> /root/stats
    grep UDMA_CRC_Error_Count /root/smartStates >> /root/stats
    
    touch /root/statsOld
    cmp /root/stats /root/statsOld
    result=$?
    
    if [[ $result -ne "1" && $result -ne "0" ]]
      then
    	echo "Something went wrong"
    	exit -1
    fi
    
    if [[ $result -eq "1" ]]
      then
    	echo "Files are different\n"
    	cat /root/stats
    fi
    
    mv /root/stats /root/statsOld
    rm /root/smartStates

Take Backblaze's 0.01% for a group of four failures. That's replacing an extra 100 drives per million, at random, and only getting the benefit of correctly predicting failures 10.4% of the time.

This is great data to have.

If you want to have a quick, but in-depth look at your drives, it'll give you lots of data, including the SMART table interpreted in a vendor-specific way. It also understands some RAID setups, and more support for this is upcoming. Windows only, at the moment.

To explain a bit of a context - SMART data comprises a set of attributes and each attribute has a value, a threshold and a raw value. Values are opaque 8-bit somethings that are only meant to be compared to thresholds. When they fall under then, then it may indicate a problem. They aren't really interesting. What's interesting is the "raw" values, but as the name implies, they are vendor-specific and require decoding. Some vendors publish the specs, but most don't. Specs that are published are often incomplete or plain wrong. So there's a LOT of reverse engineering and guesswork involved, which makes writing a SMART tool both frustrating and interesting at the same time. But if you need just the "dying / healthy" indicator, it's a very easy thing to extract from a drive.

[0]https://www.backblaze.com/b2/hard-drive-test-data.html

Such nuisance for what might be a good read.

@blackblaze I'm pretty sure you can automatize a large portion of your investigation that way.

Second, timeouts and uncorrectable errors are generally being reported to the controller as part of normal operation. So having SMART tracking them is just a bonus. Either of those two conditions is usually sufficient to kick a drive out of a functional RAID array because those are data loss events. Most drives have layers and layers of ECC, so in order to get an uncorrectable error a lot of bits need to be flipped in the target sector. For that to happen it likely indicates there is something mechanical going on which is likely to affect adjacent tracks/sectors. Of course if you never scrub your drives its possible bitrot accumulates on a perfectly functional device until sectors aren't recoverable.

In my previous life I found it much more interesting to track the rate of soft error counts during scrub operations. Particularly, in larger arrays because sometimes a drive would start getting slower (which is frequently caused by read retries in the drive itself or problems tracking the embedded servo/etc) and the correctable error counts would start to steadily rise followed by actual timeouts/uncorrectable errors. Of course these days, it seems most drives won't show the correctable error counts because it would freak people out. Instead you have to infer it from seek errors and relocated sector counts. Although, it might now be considered a SAS/SATA differentiator. SCSI has standardized log pages with more detailed information. (random google hit http://www.seagate.com/staticfiles/support/disc/manuals/scsi... page 238) Note the errors are categorized as corrected without delay, with substantial delay, and corrected on a retry. By comparison the SMART data isn't particularly "smart".