Should Power Cycle Count mark as failed when number is low?

[ironicbadger]

As per title. Smart stats show Power Cycle Count as 64 and yet this shows as a failure in scrutiny. Is this correct? load_cycle_count is 4589 and that's a little on the high side but only a few times a day and doesn't seem hugely unreasonable to me based on past (anecdotal) experience. You are correlating this against backblazes failure data I presume and that's how you're coming up with FAIL?

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   134   134   054    Pre-fail  Offline      -       104
  3 Spin_Up_Time            0x0007   138   138   024    Pre-fail  Always       -       474 (Average 477)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       75
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   098   098   000    Old_age   Always       -       15656
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       64
 22 Unknown_Attribute       0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   097   097   000    Old_age   Always       -       4589
193 Load_Cycle_Count        0x0012   097   097   000    Old_age   Always       -       4589
194 Temperature_Celsius     0x0002   162   162   000    Old_age   Always       -       37 (Min/Max 19/42)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

[AnalogJ]

Yep, this is one of the reasons why I want to eventually integrate (anonymized & opt-in) user provided SMART data. Backblaze's SMART statistics are all based on their datacenter usage, which causes some attributes to be heavily weighted against normal home-server/lab values.

https://www.backblaze.com/blog-smart-stats-2014-8.html#S12R

Unfortunately, I don't have a good short-term solution for this issue, other than ignoring Backblaze failure statistics completely for these attributes.

[ironicbadger]

Opt-in is key. Anonymize the serials perhaps but keep the drive make and model. Over time you could build up your own DB to rival Backblaze!! I'll bet this data would be very valuable to all self-hosters.

With it being opt-in, I don't see any major privacy concerns. Especially if it's anonymized and maybe even publicly viewable somehow so as to really be open and transparent.

[AnalogJ]

Yep, I hate the opt-out dark pattern, it'll definitely be opt-in (though I'll probably add a popup/wizard to introduce the feature).
Yeah, that's the idea. Backblaze has been incredibly generous sharing their data with the community, but its definitely shaped by how they run their servers. With support from a large community with diverse usage, Scrutiny's data would be more realistic for homelabs/home servers.

Yeah, that's a great idea

[bergernetch]

Unfortunately, I don't have a good short-term solution for this issue, other than ignoring Backblaze failure statistics completely for these attributes.

One solution could be to make the attribute thresholds editable. Or make different templates like desktop and server, maybe automatically assign the category when using SAS vs SATA, with the option to override.

[AnalogJ]

Attributes and thresholds with little-no real-world Backblaze data have been loosened so they no longer cause failures.

fixed in v0.4.7 🎉