[BUG] Hardware ECC Recovered incorrectly reported as disk failure

[dcelasun]

Describe the bug

This particular SMART attribute is expected to fluctuate up and down, especially during random IO, and is not indicative of disk failure. See here for some background info. Also, it seems that for this attribute lower values are worse, not better.

Expected behavior
Scrutiny shouldn't report this as failure. Seagate's own SeaTools doesn't either.

Screenshots
See the last row.

[AnalogJ]

thats interesting.

Technically this result is "correct" since the Backblaze data Scrutiny uses correlates your ECC Recovered failure value (40) with a 22% chance to fail.

The larger issue is that Scrutiny doesn't have the concept of transient failures. If any of the metrics have ever failed, then the disk will always be marked as failed (even if the ECC Recovered value resets).

This shouldn't be incredibly difficult to implement, but it may take some time.

Thanks for bringing this to my attention!

[dcelasun]

Well, I took a shot at it, hope it's welcome :)

[AnalogJ]

Commented on your PR, sorry for the (incredibly long) delay!

[korikori]

Just wanted to chime in that I have a pair of similar Seagate drives (2TB) and this attribute for both gravitates around the 38-40 mark. I also see the 22% failure rate and "Failed" status which initially startled me.

[Lebowski89]

Hello, I have Scrutiny installed on UnRaid (Docker compose). Installed it about a week or two ago, initially all my drives were listed as passed (even my 8 year power on drives). Today I have noticed that my Parity drive (Seagate BarraCuda Pro) was listed as failed. I checked critical values and it was all fine. Checked all values and it has listed a few warnings and a failure on hardware ECC recovered. Only thing I have done since the drive being listed as healthy was rebuild parity in UnRaid (converted some drives to ZFS, removed from drives from the array (into their own ZFS pool)). I've also installed and diskspeed and benchmarked the drive.

Should I be concerned? Or is this just Scrutiny being funky with Seagate drives?

[N8-Yue]

I have the same issue. Scrutiny shows higher and lower values with the Hardware ECC, but the raw value shows 0 errors ever recorded. This definitely needs to be a bug dedicated to Seagate, as they are one of the only ons to use this different raw value type. Hope this gets fixed, cause the drive is new, got tested thoroughly and the calculations show no single error ever recorded on it. Tool to calculate https://s.i.wtf

[Lebowski89]

I have the same issue. Scrutiny shows higher and lower values with the Hardware ECC, but the raw value shows 0 errors ever recorded. This definitely needs to be a bug dedicated to Seagate, as they are one of the only ons to use this different raw value type. Hope this gets fixed, cause the drive is new, got tested thoroughly and the calculations show no single error ever recorded on it. Tool to calculate https://s.i.wtf

I did an extended SMART test on UnRaid and the drive passed with flying colors. I'm going to have to get rid of Scrutiny. I don't need that negativity in my life, especially when the drive is okay. I'll reinstall when they make changes to account for Seagates differences.

ST10000DM0004-20240412.txt

[korikori]

@Lebowski89 you could still use Scrutiny, but stick to SMART data only for the "Device Status - Thresholds" setting, as by default it uses SMART + the Backblaze dataset. Both of my Seagate disks are in "failed" status with the default settings, but they pass when I switch to SMART. ¯_(ツ)_/¯

[brkr1]

you could still use Scrutiny, but stick to SMART

Will we still get notifications in case something changes?