[Feature] Add support for additional arguments when smartctl is executed - Seagate drives use 48 bit raw values and only the first 16 bits are the error data #255
Labels
Comments
AnalogJ
added
enhancement
AnalogJ
changed the title
|
Sounds like a worthwhile enhancement. I'll need to take a closer look at the smartctl documentation, but this should be easy enough to implement by expanding the |
|
This is also true for Seagate Exos X18 (18TB) drives. I would assume that this is true for most - if not all - modern Seagate drives... |
AnalogJ
added a commit
that referenced
this issue
May 28, 2022
…or device scanning, device identification and smart data retrieval. adding tests for command overrides. rename GetScanOverrides() to GetDeviceOverrides() fixes #255
|
Hey @Parlane @alexw1982 Once the beta branch finishes building, can you pull the docker images and test out the changes? Here are the relevant config file changes: https://github.com/AnalogJ/scrutiny/blob/beta/example.collector.yaml#L57-L61 https://github.com/AnalogJ/scrutiny/blob/beta/example.collector.yaml#L74-L78 |
|
I had to specify 'ata' for each device otherwise it did not try to find them? Still shows as failed, I guess you are using the value result and not the raw value:
|
|
Yeah in some cases the normalized data is what is used for backblaze reliability comparison: https://www.backblaze.com/blog-smart-stats-2014-8.html#S1R Though in this case, while the raw graph has "nicer" failure thresholds, the normalized data was chosen:
|
Merged
|
so, how do I make scrutiny use the raw value to get the drive shown as healthy? or is it simply not possible at this time? |
|
@Parlane I followed your example and that fixed most of the fields except for the It seems there might be a bug where it's using the |
Yes sorry, mine also shows as failed still. I think the real problem might now be in how smartctl calculates value. Or we could ask @AnalogJ to allow a config choice to use the raw value, with the raw_read or seek errors any value above 0 is bad IMO. And I would be happy to mark a drive as bad simply because the raw value was not 0 in the case of my seagate ironwolfs. |
|
That is not completely true values above 0 can be bad but don't have to be, there is also a temporal component if values are not to high and are stable, they do not increase, there is no need to replace a drive cause it is not failed it is fully operational which would mean it is only in a warning or error state. I am speaking from experience with ~9000 drives. |
|
I think this is working correctly now, but it requires some steps & an explanation (and possibly a Seagate specific troubleshooting guide). I don't have time to write that up right now, but I'll re-open this issue so I don't forget. |
|
I have just installed scrutiny, and am seeing the same issue with similar drives. Will follow this issue in the hope the documentation arrives. |
|
TL;DR;
Please try these steps and comment below if they work for you. Thanks! 🙏 The following explanation is documented here As thoroughly discussed in #255, Seagate (Ironwolf & others) drives are almost always marked as failed by Scrutiny.
Some analysis has been done which shows that Seagate drives break the common SMART conventions, which also causes Scrutiny's So what's the Solution? After taking a look at the BackBlaze data for the relevant Attributes (
If this is effecting your drives, you'll need to do the following:
If you'd like to learn more about how the Seagate Ironwolf SMART attributes work under the hood, and how they differ from |
|
Is there maybe a very similiar issue with the "Command timeout" on Seagate drives? It seems the soultion is reported here: https://forums.tomshardware.com/threads/very-high-command-timeout.648978/ |
I am running: beta#7a6c94a (docker ghcr.io/analogj/scrutiny:beta-omnibus) I used sqlite to update the status to not failed. Reran the "scrutiny-collector-metrics run" manually. All seagate marked as failed.
|
|
Oops I see beta is actually behind master now... I will try master instead. |
|
Yay it works :) With master#145c819 Thank you @AnalogJ |
|
Mine appears to work correctly too, thanks. |
|
fantastic, closing this out as fixed in v0.4.13 (#301) Thanks for all you help everyone!! 🥳 @fightforlife similar issue, but not quite as dire. For the command timeout attribute, scrutiny is checking the RAW value, and since the number is so absurdly high, it doesnt even fit into any of the buckets that we're looking for, so scrutiny just marks it as @Parlane yeah I developed this change on a different branch, glad you figured it out! |
|
one last question @AnalogJ Is blackblaze comparsion for seagate coming back at all or will this stay disabled now? Thanks a lot for the quick fix though. Really appreciate how much time and effort you put into this project |
|
@tadly Backblaze comparision is still enabled for Seagate, its just disabled for these 2 attributes. Regarding the RAW attribute values, the issue is that the relevant attributes are Vendor specific, so I decided to use the Normalized value in hope that I wouldn't need to worry about how the vendor decided to encode the data. Unfortunately Seagate decided to muck around with the normalized data as well (100 & 60 are both Glad everything is working for you. |
|
Hi @AnalogJ, sorry to bring this one back up, but I seem to be having issues passing the command timeout value override as a smartctl argument in collector.yaml. I add the following to collector.yaml below All that seems to happen when I do is Scrutiny skips those drives entirely during a scan run. Do you have any ideas on what might be going wrong here? |
Specify the device type like this, you may also need to specify both smart args and info args: |
|
That fixed it, thank you @Parlane! |
AnalogJ
added a commit
that referenced
this issue
Jun 25, 2022
…re the device. We need to make sure we correctly override the device. fixes #255
|
@Parlane @MattKobayashi that's definitely a bug (missing I've made a fix (and associated tests) in the |
Merged
Haha when I added device type to fix my config I assumed it was me who had done it wrong 🤣 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Seagate Ironwolf drives show as FAILED with high seek and read error counts
Expected behavior
Some way to configure per drive some extra arguments to smartctl calls.
Seagate ironwolfs use a 48 bit value that is made up of 16 bits of error count and 32 bit of total count of read or seek events.
For smartctl I have to manually specify the correct bits to read from:
smartctl /dev/sdb -a -v 1,raw48:54 -v 7,raw48:54
And smartctl without the specification:
The 200450784 value above is 0xBF2A2E0, which is only 28 bits of data (so only part of the count, not the error), the full hex would be:
00000BF2A2E0 where it would then be split as [0000][0BF2A2E0] and 0 is the actual value of Raw_Read_Error_Rate
Screenshots
The text was updated successfully, but these errors were encountered: