Multi_report Script Drive testing vs own scheduled testing

TrueNAS General
1

Hi,

I finally updated my truenas setup and with it the multi_report script as well.
Previously I have had scheduled S.M.A.R.T. Tests through the GUI and used multi_report to send me the results.

Now I noticed that the multi_report script does S.M.A.R.T tests for you.
Do I not need to have my own scheduled S.M.A.R.T. Tests anymore?
Or do I keep them and just disable the S.M.A.R.T. Tests in the multi_report script?
I guess either one is fine?
I do not have NMVe Drives so it does not matter they are unavailable in the GUI but can be tested through the script.

I don’t want to run too many tests on my drives.

thanks for your help.

2

use the way you pref, what accomplish better your use case.
I use the GUI for the dayli SHORT on all the disks (NVME are excluded, not performed, but IMHO not so important), and instead i let handle the Multi Report the LONG weekly, so the most intensive test are spread along all the week (instead of be performed one day for all disks together), and also NVME are tested.
Off course you can also spread LONG tests by GUI, but multi report provide an easier way to accomplish this

3

I couldn’t agree more. Whatever you are comfortable with.

For Drive_Selftest version 1.05:
If you have a lot of drives (whatever your threshold for scheduling pain is), the script will ensure each drive is tested within the given periodicity, with one catch… The script must be run every “authorized” (defined in the script) day to ensure no drives are skipped. It is that last part I am also trying to solve, just in-case someone does not run the system for a few days, could be due to failure, hardware upgrades, you left town for the weekend and turned off the server, whatever. It is a hole I want to patch (Update #3).

So, if you have 20 drives, 90 drives, 200 drives, or even 4 drives, the script will schedule the testing for you. You can see how this helps those with a lot of drives, but even us with few drives (I have 4 drives in each system) can use it.

I am working on an update, it is taking me longer than I expected but that seems to be my normal now that I’m retired, more things to do.

The update (from my notes):

#   1. A RESILVER of a pool regardless of the time left over will not allow any SMART tests, long or short on THAT pool.  Priority is given to the RESILVER.
#   2. A SCRUB of a pool that has less time than SCRUB_Minutes_Remaining variable will run a SMART Long test, a value larger than SCRUB_Minutes_Remaining will run a Short test.
#   3. The drive testing need to be recorded and checked each run against the LONG testing schedule to ensure it wasn't skipped.  This can be bad/tricky so define a maximum number of missed drives that could be tested each day so we do not overload on the day the system starts testing again, to catch up on missed drives.```

These are subject to change and do change, normally I add or just adjust how things are done.  I'm certain #3 will change but the goal will be the same.
1 Like