What does a shingled (SMR) hard drive failure look like in logs, and what does SMART miss?

The measured behaviour is a cliff, not a decline. Ars's 32 KiB test, ServeTheHome's resilver and the University of Minnesota benchmark all show a drive that works at normal speed until a conventional write area is used up, and then collapses. The Minnesota authors found that each cleaning pass dropped throughput from over 100 MB/s to about 0.1 MB/s, and that a workload spread over the whole drive made the first cleaning last so long that their test program broke after about 100 min; they guess the drive throttled writes long enough to cause timeouts in the Linux stack. That paper is about a prototype host-aware drive, so it supports the mechanism, not the size of the effect on a retail WD Red. Western Digital's own post says the same mechanism in plain words: sustained random writes during ZFS resilvering leave no idle time for the drive's background work.

The logs show the errors only after the cliff has turned into failed commands, and the usual health signals stay quiet. In the one published log set, SMART overall health said PASSED, and reallocated, pending, uncorrectable and CRC counters were all 0 at the same time as an ATA error count of 7,487 (the latest 24 shown were IDNF). A health check built on those four attributes would have reported a healthy drive. What did record the event was the ATA extended error log, the kernel's 'logical block address out of range' sense text and the filesystem's own write-error counter. None of the opened sources shows a SMART attribute that tracks the slow phase before errors start; timing seen from the host (peak latency, pauses over 60 s) is the only early sign in the evidence, and no source gives a threshold for it.

The error text does not identify SMR by itself. The same IDNF and 'logical block address out of range' lines appeared in a report on four drives that the commenter checked were not SMR, ; those errors began after the pool grew from 2 to 4 drives, paused for 9 days after an AHCI to IDE change and returned on a different controller, and the commenters suggested controller or power-supply causes. The ordinary link counters (CRC errors, PHY ready drops) are separate evidence and, in the SMR log, showed 0 CRC errors. The two readings can only be told apart by the drive model, firmware and the write pattern at the time, which the logs of the CMR report do not settle.

What is unknown is larger than what is measured. Three testers used the same model and firmware: the iXsystems lab and one user saw the failed state, while ServeTheHome and Ars saw slowness only. The differences in workload (replacement into a degraded vdev, array size, other load, prior writes) are described but not isolated by any source. Western Digital says non-ZFS rebuilds on Synology or QNAP systems take as long as CMR or slightly longer, and Ars's mdraid result is consistent with that for one drive. Whether the failed state is a firmware bug or the drive's normal behaviour under an unusual access order is argued by the interviewee and commenters but not shown by the vendor. No source opened here gives a failure rate for SMR drives, so this page does not claim SMR drives fail more often; it documents what an overloaded one looks like in logs.