Kris and Chris return after their week off to bring you some updates on new SMART Smarts coming to TrueNAS in this fall’s 25.10 build, a new way to monitor your drive health with the Scrutiny App, and answer some viewer questions - from encryption performance, to SAS multipath, to the challenges of dual-actuator drives working with TrueNAS.
Where’s the update?!?!?! 
Just kidding, looking forward to it.
I really appreciate the news on the SMART implementation and Scrutiny. I hope you make my little script obsolete, Please!
Personally I’m a bit confused as to why NVMe would need to use multiple name spaces. Treating an NVMe as a single partition drive (a single namespace) sounds like the most compatible way forward, which is how I use mine right now, however I’m not an NVMe expert. I’m sure there must be some scenario where using multiple namespaces makes sense.
Thanks for another TrueNAS Tech Talk!
For most use-cases, the NVMe drive is just L2ARC or a pool vdev.
However, the observation is that NVMe drives are getting so large and so fast, that there is some sense in having one NVMe drive act as multiple drives. So long as a single drive failure does not lose the pool/data.
You mean like Multipath or dual-actuator drives? Okay, kind of kidding and kind of not. I could see this becoming the same problem which removed multipath support from TrueNAS.
With that said, I could see a single drive as an L2ARC or multiple drives for metadata. And I’m sure there are a few others that would be perfectly suited for multiple NVMe namespace use.
You are correct, the speeds are crazy fast so there is potential for a lot of good speedy machines to immerge.
Agreed… it needs to be done carefully. 1 drive acting as 2 data vdevs is not going to be reliable.
One drive acting as SLOG and L2ARC for multiple pools…
I still expect people to screw this up “Unless” there is logic to prevent this. At least with NVMe, you are dealing with namespaces so TrueNAS can validate drive/namespace assignments do not contradict practical and safe implementation.
Example: nvme0n0 and nvme0n1 cannot be assigned to the same pool. I do mean pool, not VDEV. This does not apply to a namespace being used for a safe single drive usage such as L2ARC or SLOG. Failure of these whole drives when shared with a pool should not constitute data loss/corruption if built in at least a RAIDZ1 configuration.
Someone will want an exception to do that but iXsystems should apply common sense and just fix it where a person cannot screw up if using the TrueNAS GUI to create a pool.
When it comes to manual creations of a pool, let the stupid do what they want, you can’t save everyone and they often learn from their mistakes. Don’t we all?
Sorry for getting a bit off topic but that TrueNAS Tech Talk was a very good one, very informative and for me exciting with new features in the future.
And notably, a drive that has proper NVMe namespace support along with a solid QoS (Quality of Service) implementation could theoretically allow for this kind of split-usage scenario without negatively impacting either.
I currently have a large SSD that I (manually) split into multiple partitions and then (manually) use each partition as a L2ARC for a different pool. It works great and there’s performance to spare.
Using namespaces would just be more… proper.
In this episode you mentioned that there is new disk temperature polling that should allow Scrutiny to show more up to date information.
Can you share any more information? I’ve upgraded to Fangtooth, but I’m currently only seeing temperature polling every 24 hours, or on restart of the container.
