mirror of
https://github.com/007revad/Synology_SMART_info.git
synced 2026-04-24 23:55:48 +03:00
[GH-ISSUE #51] Test version that uses synodisk instead of smartctl #70
Labels
No labels
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Synology_SMART_info#70
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @007revad on GitHub (Nov 17, 2025).
Original GitHub issue: https://github.com/007revad/Synology_SMART_info/issues/51
Originally assigned to: @007revad on GitHub.
@PeterSuh-Q3 @framps
Do you guys want to test this version? It gets the smart attributes from
synodisk --smart_info_getinstead of smartctl. I had to add decoding of Seagate SMART attributes 1, 7 and 195 for when the script is synodisk instead of smartctl7.It still uses smartctl to get the health, and defaults back to smartctl is
synodisk --smart_info_get /dev/"$drive"returns "Failed to get the smart info".It should show a lot more attributes for SAS drives than smartcl does.
https://github.com/007revad/Synology_SMART_info/blob/test/syno_smart_info_synodisk.sh
If it works okay for SAS drives I'll update it to use synodisk for the -a option as well.
@PeterSuh-Q3 commented on GitHub (Nov 17, 2025):
@PeterSuh-Q3 commented on GitHub (Nov 17, 2025):
@framps commented on GitHub (Nov 17, 2025):
I have no clue about your updates. But the script doesn't work any more as before.
That's what I do in order to test your script:
rm smart.logto initialize the environmentsyno_smart_info.sh -iand getThat's OK.
Now I call
syno_smart_info.sh -iagain and getThat's OK again.
Then, in order to simulate an increase in the error rate, I edit smart.log and assign to the Raw_Read_Error_Rate number 8. In previous versions I saw the previously detected error rate 3 assigned. Now it's empty and I have to add the new number.
Now I call
syno_smart_info.sh -iagain to get a notification the rate increased from 3 to 8. I now getThe number increased and an decrease is reported. And the added 8 in
Raw_Read_Error_Rate=8line now vanishedRaw_Read_Error_Rate=. Very confusing.If I use current version I get
which is OK and I can see the updated error rate in smart.log.
@007revad commented on GitHub (Nov 17, 2025):
@PeterSuh-Q3
What does
synodisk --smart_info_get /dev/sdgreturn?@007revad commented on GitHub (Nov 17, 2025):
@framps That's an easy fix.
Change line 606 from this:
to this:
It's using
synodisk --smart_info_getinstead of smartctl.@framps commented on GitHub (Nov 17, 2025):
I now see smartlog updated with the measured values and can update 3 to 8. But then I still get
@007revad commented on GitHub (Nov 17, 2025):
If you changed 3 to 8 in the log then
3 Decreased by 5is correct.@framps commented on GitHub (Nov 17, 2025):
Are you kidding? If I increase a value from 3 to 8 it was increased by 5, not decreased by 5 😳
@007revad commented on GitHub (Nov 17, 2025):
You changed it in the log to 8. The smart value is 3. 8 - 3 is a decrease.
@framps commented on GitHub (Nov 17, 2025):
It's not my day 😢 You are right. With your patch everything works fine on my system.
I set the rate to 1 in smart.log
Is there any reason you use
smart.logto persist the latest measurements and not the<scriptname>.log? I find it much more consistent to use<script name>.loginstead of some random name likesmart.log@007revad commented on GitHub (Nov 17, 2025):
No reason. I suspect smart.log made sense at the time because it was a log of drives' smart values and not a log of the script's output.
I've changed it to syno_smart_info.log in the next version. The script probably should check if smart.log exists and rename it to syno_smart_info.log
@framps commented on GitHub (Nov 17, 2025):
I just thought about the extension and it's actually not a log file but a state file. Maybe
<scriptname>.stateis a better name ?@007revad commented on GitHub (Nov 17, 2025):
Then I thought maybe .stat or .att
I think stat is possibly best.
@007revad commented on GitHub (Nov 18, 2025):
@PeterSuh-Q3
Can you try this new test version in default mode and confirm that it now shows a lot more attributes for SAS drives.
https://github.com/007revad/Synology_SMART_info/blob/test/syno_smart_info_synodisk_test2.sh
For SAS drives it should look like this:

@PeterSuh-Q3 commented on GitHub (Nov 21, 2025):
@PeterSuh-Q3 commented on GitHub (Nov 21, 2025):
@007revad commented on GitHub (Nov 21, 2025):
@PeterSuh-Q3
Do all 4 SAS drives really show the same "Raw: 57" for Hardware_ECC_Recovered with
synodisk --smart_info_get /dev/sataX?@PeterSuh-Q3 commented on GitHub (Nov 21, 2025):
The results for SATA5 are already shown above, although not for 4.
Wouldn't the rest yield similar results?
I can't test them right now.
The four disks are currently in the same RAID group. Could this be related?
The fact that all four disks are 57 is suspicious.
@007revad commented on GitHub (Nov 22, 2025):
I guess it could be a result of using a RAID group. It's also suspicious for the 4 drives to have the exact same temperature.
I had someone with 2 HD6500s test the script as well. On a real HD6500
synodisk --smart_info_get /dev/sasXreturnsFailed to get the smart info of /dev/sas8. When that happens the script defaults back to smartctl.https://www.synology-forum.de/threads/smart-werte-auslesen-und-interpretieren.131057/post-1263762
https://www.synology-forum.de/threads/smart-werte-auslesen-und-interpretieren.131057/post-1263763