multi_report.sh version for Core and Scale 3.0

[Davvo]

I'm sure its sensible information to know but I have no intention of acting on it for my boot drive.

So you don't run SMART tests on your boot drive?

 

[snowlucas2022]

So you don't run SMART tests on your boot drive?

I do. And I am.

I don’t want a warning message for that particular ssd for that particular information.

I’m aware the ssd is old. I assume that is what the result is telling me.

 

[joeschmuck]

Hi, thanks for the script. Is there anyway to ignore "Last Age Test" for my SSD. I can't find a setting for this in the config. I'm sure its sensible information to know but I have no intention of acting on it for my boot drive.

The simple answer is no, you cannot ignore a single drive type.
The long answer is, the value testAgeWarn=2 sets the value for all drives. I expect all drives to be SMART Tested at some periodicity.

Please note that the SMART Short/Long tests are Read Only tests, they do not write to the drives if you are concerned about wearing out a SSD.

You could go into the script and change some of the coding around to make it ignore this value for SSD's only, and here are the two lines you would need to alter and make :

Code:

if [[ $testAge -gt $testAgeWarn ]]; then testAgeColor=$warnColor; else testAgeColor=$bgColor; fi
if [[ $testAge -gt $testAgeWarn ]]; then printf "Drive: "$serial" - Test Age = "$testAge" Days<br>" >> "$logfile_warning"; fi

I'm doing this for work so I can't test this out but I'm thinking you could change it to this which should ignore all SSD's, but not NVMe's, that is slightly different:

Code:

if [[ $detail_level != "SSD" ]] && [[ $testAge -gt $testAgeWarn ]]; then testAgeColor=$warnColor; else testAgeColor=$bgColor; fi
if [[ $detail_level != "SSD" ]] && [[ $testAge -gt $testAgeWarn ]]; then printf "Drive: "$serial" - Test Age = "$testAge" Days<br>" >> "$logfile_warning"; fi

 

[joeschmuck]

I’m aware the ssd is old. I assume that is what the result is telling me.

LOL, no, Test Age is how many days (24 hour periods) since the last SMART Long or Short Test was run.

I run a SMART Short test daily and recommend that as well to people, but if you were to run a SMART test weekly then you would want to change the testAgeWarn value to maybe 15 which would allow for skipping one test cycle. Just a thought.

 

[snowlucas2022]

Ha. Sorry.

I’d better run a smart test then.

Thanks.

 

[snowlucas2022]

So I was a little confused as all drives are set to run smart tests. The result I'm getting for my SSD is a warning "Test Age = 952 Days"

I've just run a short test and an extended test without errors. It does show other tests that were also completed without error s the regular testing appears to be working.

The only other thing that might be part of this is the lifetime hours appears to have reset as its currently 177 but was 3066. But I think this is normal behaviour for the hours to reset.

So I have this warning that appears to be wrong?

 

[joeschmuck]

The only other thing that might be part of this is the lifetime hours appears to have reset as its currently 177 but was 3066. But I think this is normal behaviour for the hours to reset.

Nope, not normal at all.

I will send you a message and we can troubleshoot the issue outside of thread.

 

[joeschmuck]

So I was a little confused as all drives are set to run smart tests. The result I'm getting for my SSD is a warning "Test Age = 952 Days"

So we took this situation offline and the Samsung 840 EVO drive is reporting some odd values. The drive has over 88565 hours (about 10 years) on it and the self-tests are unable to report numbers that high so they are reporting an odd number which is generating the warning message. This is not the first time I've seen this happen so I updated the script to add a new custom setup which should work fine now to ignore the Test Age for this one drive. I only provided the new script to @snowlucas2022 but it will be included in the next official version. This update only affects @snowlucas2022. He was using the script correctly so no error on his part.

For everyone else out there, if the script is not working as expected, please say something. I'm more than happy to investigate and if it makes sense, update the script.

 

[diedrichg]

FWIW, I also had this issue with my Supermicro SATADOM boot drive. Even though my short and long SMART tests were completed I was getting the old test age warning. I wound up ignoring the boot drive in the script. I'd also like to get this fixed.

 

[joeschmuck]

FWIW, I also had this issue with my Supermicro SATADOM boot drive. Even though my short and long SMART tests were completed I was getting the old test age warning. I wound up ignoring the boot drive in the script. I'd also like to get this fixed.

Send me a message, run the script with the -dump parameter which will generate and attach two files per drive (and "a" and "x" file) to your email report. I need drive data files for the SATADOM to examine them and see what I can do to fix it for you. If you have more than one SATADOM, send all of them. If you want to send me all your files, I'm good with that.

Maybe I need to add a feature to allow the user the ability to add a drive by serial number and choose which alarms to ignore. It would be pretty complicated but maybe I could look into it this weekend.

 

[emk2203]

+1 for the feature to ignore specific alarms, this was the ony annoyance I saw when running the script. I have a SATA M.2 -> USB adapter for my boot pool, and I see the same issues with test age even when I tested it a mere minutes ago. So, looking forward to the new version.

Another issue:

The script works fine at least on one of my devices, but another one has issues. When I start the script, it aborts with the following error(s):

Code:

N54LNAS% sudo ./multi_report_v1.6e_11_Nov_2022.sh
Multi-Report v1.6e dtd:2022-11-11 (TrueNAS Core 13.0-U3.1)
Configuration File Version Date: 2022-11-11
Failed conversion of ``2020-Oct-19_03:58:30'' using format ``%Y-%b-%e_%H:%M:%S''
date: illegal time format
usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt]
            [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
            [[[[[[cc]yy]mm]dd]HH]MM[.SS] | new_date] [+output_fmt]
Failed conversion of ``2022-Aug-28_19:37:29'' using format ``%Y-%b-%e_%H:%M:%S''
date: illegal time format
usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt]
            [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
            [[[[[[cc]yy]mm]dd]HH]MM[.SS] | new_date] [+output_fmt]
./multi_report_v1.6e_11_Nov_2022.sh: line 2414: [[: ---: syntax error: operand expected (error token is "-")
./multi_report_v1.6e_11_Nov_2022.sh: line 2415: [[: ---: syntax error: operand expected (error token is "-")

It's in both the same TrueNAS version, and they should have a very similar configuration. So what's going on here? What can I do to investigate it?

 

[joeschmuck]

+1 for the feature to ignore specific alarms

I started working on it yesterday but it will be at least a week or more before I have it working properly. Then after a few folks try it, I get some feedback, then put the finishing touches on it.

The script works fine at least on one of my devices, but another one has issues.

So what's going on here? What can I do to investigate it?

I'm not sure to be honest. All I know is there is some date conversion that is not working. I will PM you to collect more data so we can see where it's failing. Did a previous version work and just verison 1.6e failed?

Thanks

 

[freenas-supero]

I am also observing the same (or similar) problem with "date"

Multi-Report v1.6e dtd:2022-11-11 (TrueNAS Core FreeNAS-11.3-U5)
Configuration File Version Date: 2022-11-11
date: illegal option -- I
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]

I have to CTRL+C the script because it hangs in there...

 

[joeschmuck]

There is a fix for the "date" issue in v1.6e (and earlier) that should fix for non-English configurations, assuming that is the issue. If you want to use the v1.6e version, update the script and add the following line on line 3 of the script LANG="en_US.UTF-8" and that should fix it. I provided @emk2203 the fix a few days ago but it took time to identify the root cause.

This fix will be in all future versions as well. And a new version is close to being released which will address custom drive configurations. This should allow me to remove the custom versions for a few people and let anyone customize. So give me at least one more week for testing before I post it. If you want a beta version, PM me and I'll send you a copy. The changes have not been tested on Scale yet. Once I finish my testing on Core, then I will test on Scale.

Of course, please keep letting me know if you run into an error/issue. I still prefer to fix all problems, no matter how small they are.

 

[joeschmuck]

Here is the current beta version of 1.6f and I think this one will end up being the final version as well. It has been tested on Core and gently tested on Scale.

This version will update your multi_report_config.txt file for the Custom_Drives variable. This is a new feature and improved from the previous beta version from a few weeks ago. This one works very nicely and all unique custom hacks currently incorporated should be supported by using this new feature and in the next version the custom hacks will be removed. Well that is the plan.

Here is the Changelog:
# v1.6f (26 December 2022)
# - Added recognition for WDC SSD "230 Media_Wearout_Indicator".
# - Adjusted the language to English for the Date calculations.
# - Updated datestamp2 "date" command to be compatible with FreeBSD 11 and earlier.
# - Updated Zpool Status Report to display Used Space Capacity when using the "zpool" reporting configuration.
# - Added customizable alarm setpoints for up to 24 drives.
# -- This feature allows for customizing drives which do not fit into the default parameters.
# -- It is not intended to individualize each drive, but you could if you wanted.
# -- This allows the option for removal of the three custom code options.
# - The configuration file in the email will now change to FreeNAS or TrueNAS based
# -- on the software running vice FreeNAS hard-coded.
# - Corrected several spelling errors throughout script.
#
# The multi_report_config file will automatically update previous versions to add new features.
#
# - Future Plan: Remove custom code for snowlucas2022, diedrichg, and mistermanko in version 2.0.

I honestly can't think of a single thing I could add to this script. I think it covers all bases, until some new drive comes out and has a unique recognition problem, it always happens right after I put out a change.

I hope everyone has a Happy New Year!

 

[Davvo]

Looks like Santa enjoyed his trip.

 

[awasb]

Dito. Works nice on the below mentioned test system.

 

[joeschmuck]

Here is the final release version for v1.6f and it should be posted to the resource once @TooMuchData posts it. Until then, it's attached here.

 

[freenas-supero]

@joeschmuck : the change you did on "date" command worked perfectly!!! Thanks a lot for your hard work, the script works well now!

 

[TooMuchData]

TooMuchData updated multi_report.sh version for Core and Scale with a new update entry:

Happy New Year (and new version)

Per joeschmuck, this version adds a new drive model and also adds the ability to customize alarm settings for individual drives. It fixes a Date issue with FreeNAS 11, and date calculation issue for foreign languages (German was the issue it came up in).

Enjoy.

Read the rest of this update entry...