Triaging a Drawer of Old Drives: SMART, USB Enclosures and What to Keep

Every homelab grows a drawer of drives: pulled from old laptops, retired from an ESXi host, left in a Raspberry Pi that got repurposed. I finally went through mine. The rule was simple: read-only tests only, so nothing on a drive gets changed until I’ve decided what to do with it.

The toolkit was smartctl and a handful of USB enclosures:

sudo smartctl -a /dev/sdX          # health, attributes, error log
sudo smartctl -t short /dev/sdX    # 2-minute self-test, reads only
sudo smartctl -l selftest /dev/sdX # the result

Eleven drives and five enclosures later, here’s what I found.

Head parking was the clearest signal

Laptop hard drives save power by parking their heads off the platters when idle, and each park-and-unpark is counted as Load_Cycle_Count (attribute 193). Drives in this class are typically rated for around 600,000 cycles. A laptop drive that ended up in an always-on box, with something waking it every few seconds, burns through that fast.

The top four are past or right at the rating. The Hitachi had parked its heads 5.8 million times, nearly ten times over. It passed its health check with a clean surface, and it’s still going to recycling: a head-load mechanism that far past its design life can stop spinning up with no warning.

The chart also shows the limit of this one number. The WD Scorpio Blue sits comfortably below the rating and is the worst drive in the pile. It fails its own SMART health check, with 541 reallocated sectors marked FAILING_NOW and 53,888 logged errors, and its self-test aborted 10% of the way in with “unknown failure”. Head wear and surface wear are separate ways to die, so you need to look at both.

Every drive

Serial numbers left out. “Hours” is power-on hours, except for the Seagate 500GB, whose power-on counter had wrapped. For that one I used Head_Flying_Hours.

Hard drives

Every self-test I let finish passed, except the WD Scorpio’s. Three drives got unplugged before their two minutes were up, but their attributes had already decided it.

SSDs

SSDs have no heads to park. What wears out is flash, so the numbers to watch are the wear indicator and the spare blocks.

All three SSDs had run for years in always-on machines. None had a single logged error, and all three passed their self-tests. The 860 EVO came out of an ESXi host where Home Assistant, Cacti and Nagios had written about 75 GB a day to it for six and a half years. It’s halfway through its rated endurance, with not a single error.

The enclosures matter as much as the drives

Each enclosure has a USB-to-SATA bridge chip, and the chip decides how fast the drive can go, whether SMART works, and whether an SSD gets TRIM.

The two USB 2.0 enclosures cap any drive at about 35 MB/s, so filling a 500 GB drive takes around four hours. The uas driver on the JMicron chips is the newer, faster protocol, and those are the ones I’d pair with an SSD.

None of them had TRIM enabled by default (provisioning_mode reads full). The JMicron chips can usually do it with a udev rule that sets provisioning_mode=unmap, which is worth doing for an SSD that lives in one.

The Initio took some trial and error. Plain smartctl failed with unsupported scsi opcode, and so did -d sat. Only the 12-byte variant worked:

sudo smartctl -d sat,12 -a /dev/sdX

Gotchas, collected

• A PASSED health check doesn’t mean much. It only fails when an attribute crosses the manufacturer’s threshold. Four of the drives I’m recycling passed. Read the attributes and the error log.
• The short self-test samples a small part of the disk. The Toshiba 80GB passed it while holding 12 unreadable sectors.
• Some Seagate raw values look alarming but aren’t. Raw_Read_Error_Rate, Seek_Error_Rate and Command_Timeout pack several counters into one big number. Look at the normalized value instead.
• Power-on hours can wrap. One Seagate logged errors at hour 8,760 but reported 4,764 hours of use. Head_Flying_Hours was the sane number.
• Turn off desktop automount while testing. My file manager mounted the failing WD’s partition the moment I plugged it in, and immediately hit read errors. That’s extra wear on a drive that has none to spare.
• Don’t unplug a drive in the middle of a wipe. A dd from /dev/zero over USB runs about 130 MB/s, so 500 GB takes an hour. I swapped the HGST out at about the two-thirds mark, so it needs a second pass.
• A failing drive may not finish a wipe. For the WD Scorpio, physical destruction is quicker than waiting for dd to stall on bad sectors.

That leaves five drives worth keeping, one drive for spare backups, five for recycling, and three USB 3 enclosures to keep. The two USB 2.0 enclosures are spares.