From 5adceeb9a5d6be49d5a10175711ce6c09bcb4584 Mon Sep 17 00:00:00 2001 From: Jason Kulatunga Date: Thu, 12 May 2022 21:58:36 -0700 Subject: [PATCH] update with SMART vs Scrutiny details. --- docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md b/docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md index 50858f4..0db3fb8 100644 --- a/docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md +++ b/docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md @@ -118,6 +118,19 @@ instead of the block device (`/dev/nvme0n1`). See [#209](https://github.com/Anal ### Volume Mount All Devices (`/dev`) - Privileged +## Scrutiny detects Failure but SMART Passed? + +There's 2 different mechanisms that Scrutiny uses to detect failures. + +The first is simple SMART failures. If SMART thinks an attribute is in a failed state, Scrutiny will display it as failed as well. + +The second is using BackBlaze failure data: [https://backblaze.com/blog-smart-stats-2014-8.html](https://backblaze.com/blog-smart-stats-2014-8.html) +If Scrutiny detects that an attribute corresponds with a high rate of failure using BackBlaze's data, it will also mark that attribute (and disk) as failed (even though SMART may think the device is still healthy). + +This can cause some confusion when comparing Scrutiny's dashboard against other SMART analysis tools. +If you hover over the "failed" label beside an attribute, Scrutiny will tell you if the failure was due to SMART or Scrutiny/BackBlaze data. + + ## Hub & Spoke model, with multiple Hosts. When deploying Scrutiny in a hub & spoke model, it can be difficult to determine exactly which node a set of devices are associated with.