Ok, so I obviously misunderstood how smartd was supposed to work, and as I understand it now, it won’t be working at all in 25.10 and beyond unless we enable / trigger it ourselves?
Beyond that, I presume this also means that OEM/SKU specific alerts previously associated with smartd (like dropping helium levels) will no longer trigger warnings from the NAS, cause it to mail us unhappy news automatically, etc, correct?
I genuinely think it was intended to run, otherwise I have no idea how the drives are being monitored, but then again, I most certainly don’t know everything, not even close.
I guess they could have rolled a version of their own, but that is time and money when you already have a product which performs this action, and does it very well. I’m hoping @HoneyBadger responds, or maybe @kris does with some sort of answer. I hope the answer is “Thanks for letting us know, we will work on that for the next release.”
As for running smartd ourselves, we might be able to run it from Post-Init in the GUI. With that said, I’d rather know more about what is going on before I assume something and run down the wrong path.
They are monitored with smart.py.
In community edition, the only SMART attribute that is monitored is “uncorrected errors”. There is also monitoring of test failure, but I don’t consider that a attribute.
With SATA drives only the attribute with ID 187 is monitored. Which is an attribute that isn’t even used in my drives. So the entire thing is useless for me and probably many others.
All of this points to the need for better documentation re: the changes being made under the hood.
We went from making some changes and removing the SMART GUI scheduler pane due to insurmountable coding issues to allegedly jettisoning most of SMART monitoring other than 1 or 2 attributes. More documentation is needed.
Sysadmins shouldn’t have to parse through GitHub commits to figure out what infrastructure is being removed. If a lot of thought went into these changes then the documentation should be available, easily condensed and presented in the release notes.
For example, a simple table that illustrates what SMART attributes TrueNAS will continue to monitor, which it previously monitored, and what Scrutiny and @joeschmuck excellent collection of scripts can do to re-enable monitoring of various attributes that 25.10 and beyond no longer intend to review.
Thank you. So they did spin a custom version. But they sure did use the term ‘smartd’ in the video a lot.
Not being a python programmer, a lot of that escapes me.
I guess the point really is, so long as TrueNAS is monitoring the drives for serious errors in real-time, then the outcome is the same, regardless of using smartd or a different method.
EDIT:
Thank you for the kind words. My scripts will continue to report as they currently do until such a time that they prove to be useless, or my death, or if it is time to pass the buck to someone else.
I’ve been running Truenas since Freenas 9.x days, about 12 years now. One of my pools dates back from my time and has survived intact though multiple hardware upgrades and migrations, an assortment of drive failures (including 2 drives failing simultaneously - RaidZ2 saved the day).
I had an HBA go bad on me, but only on one channel. ZFS flagged the drive as bad, but it was passing Smart self-checks, and thanks to that level of detail, I was able to isolate the cause of the issue. Swapped out the HBA, and the drive came up perfectly.
I’ve had SATA cables go bad a few times (I live in a humid area, and these kind of issues are common). Again, Smart helps understand where in the chain of HBA/cabling or backplane/drive the issue is actually happening. If I get a new set of drives, I note what the Smart Values are initially, then keep an eye on them to see how they change over time. If any one drive has a value or two that starts diverging from the other drives in that set, I start keeping a closer eye on it or dive into researching that specific attribute. Sometimes a cable reseat fixes it, sometimes it’s a sign that this drive is liky to fail soon and start seeking a replacement or open up a warranty case proactively if the drive is nearing it’s warranty window.
Smart is incredibly useful, and it’s baffling that this is even a discussion. Run some safe defaults for the newbs, but let those of use who use it have convenient access to it without resorting to unsupported CLI scripts that a future update can break.
I’m still holding out on Core 13U6 becuase I only use Truenas as a NAS. Ever since Scale came out it seems like the development process has become quite chaotic and unclear, and I am having serious concerns.
Please, forget about Apps and VMs and Containers and other fluff. There are other, IMHO better, systems for that could utilize Truenas for shared storage/SAN. Truenas core competency is (should be) rock-solid data storage with robust tools to support that mission.
Apps and containers (in the form of plugins and jails) have been in FreeNAS since the 8.x days. The plugins were never done especially well, but they’ve been there. IOW, this isn’t anything new. SCALE does apps much better, but the capability has been in the product for 15+ years.
Of course. But they have never been the core value proposition of Freenas, Truenas Core, Or Scale. There are alternatives where the Apps are primary and the storage is secondary. With Truenas, the storage is the whole point, and apps are a nice-to-have, although some basic app/vm/docker support is table stakes with consumer-focused “NAS” systems. I’m just voicing my disappointment that support for storage above all else is being compromised. There is evidently a change in goals, objectives, audience, and messaging happening.
