Yes, that is all correct. “If one was going with a hybrid pool anyway…” “…redundant special vdev…”.
In a lot of cases I have observed that my spinning disk storage is fast enough for throughput, but I notice poor performance in things like directory listings and operations. The server has plenty of memory (64GB for a single user system, about 55GB available for cache). I’m not sure if I am game to try a special given the risks, but it’s an interesting idea.
If you have a sync-write workload and want them to have good SLOG performance, then yes. The preferential order will be SLOG → Special → Pool - and there’s good odds that a special vdev even without PLP will be faster than spinning pool disks at handling sync writes.
The issue is NOT speed, but data integrity. SLOG or Special vDev used as ZIL, without PLP is not data safe for synchronous writes.
PLP does not have to be super cap based, (mini-battery). It can be writes to SLC cache, or direct write to the final non-volatile cells. As long as the data is in stable storage, (aka NOT in DRAM cache), before the sync write is acknowledged.
This also implies that the in pool ZIL, (without SLOG or Special vDev), needs to be PLP. Meaning in the past flash storage was not common for data vDevs, but that’s changed in the last 5 or so years. I wonder if this has impacted in pool ZIL sync write data integrity?
Yes, unless you are prepared to delete the snapshot, the ZFS rewrite does not reduce space.
If I understand ZFS rewrite correctly, it does NOT re-stripe the data. Some people want to use zfs rewrite to re-stripe RAID-Zx data after adding one or more data columns. This zfs rewrite does not do that as far as I can tell.
And it is not just snapshots impacted by zfs rewrite. This will impact block clones and hard links, both of which will increase storage after a re-write.
In-flight PLP is not required for data safety - synchronous writes handle that. ZFS does not trust your disks and as such sends SYNCHRONIZE CACHE for sync writes that need to land in the ZIL (whether that’s in-pool or on a SLOG) and will not reply back to client that the write is complete until the SYNCHRONIZE CACHE command completes.
A lack of PLP makes sync-write performance suck but is not required for safety.
PLP at rest on the other hand is required for all devices in ZFS - SLOG, special, or pool members - this is the guarantee that the device is self-stable with regards to wear leveling, its internal FTL, and more, and won’t spontaneously ruin something when it decides to relocate bits from physical location A to physical location B while retaining the same LBA upstream.
PLP-at-rest used to be limited to an SSD-based risk, but because HDD’s didn’t want to be left out, someone invented SMR to let spinning disks get in on the failure domain as well. 
The window of risk opens when a drive claims to honor the SYNCHRONIZE CACHE command but firmware assumes or overrides and sets the IMMED flag on the inbound command - which counterintuitively isn’t “immediately synchronize” but “immediately return TRUE” or in other words lie about the safety of the cache flush. Thankfully said drives were mostly limited to a very early generation of SSDs from manufacturers who have since Chapter 11’d themselves into oblivion.
for my truenas project i made a huge mistake.
i bought dramless ssd for use with truenas. at the time all i thought it was cheap. didn’t think it mattered, but apparently it does.
i use the ssd for installing the truenas apps and os. that said, i didn’t particularly notice issues….
but AI said, it defeats the purpose for using ssds when using dramless for truenas. so there is that.
my point is, make sure you use the correct ssds for truenas, dont make my mistake.
but considering prices in Q4 2025 going into 2026, this would be too costly to undo. so since it just works right now, i left it as is. but lesson learned for next time 
so then you’d be asking, what then are dramess ssd good for. it’s for your gaming pc as like a secondary drive for games. your bios needs the setting enabled (usually the default is enabled) which lets the ssd use your ddr5 ram instead of it’s own. so for gaming, it would just work fine.
But for OS, dont use dramless. Also if you use something OBS, dont use dramless either.
qlc is still worse compared to tlc last i checked 
as for the sudden power loss protection, all i know about that was crucial ssds had this feature, which was why i bought them previous for my nas use. but since they are winding down sales for crucial branded ssds, i dont know what ssd is a good choice now for that. but definitely dont get dramless ssd for truenas.
Crucial’s SSDs have the “power loss at rest” type of protection. Fine for pool members but they won’t make good SLOG devices.
I ordered a couple used enterprise SSD to try out a special vdev mirror. My plan is to use it for all metadata and then use the small blocks feature on a per-dataset basis to store specific datasets like databases and ix-apps on the SSD. I will report back the results.
The metadata benefits will be more significant if your metadata does not fit in your RAM ARC.
The metadata fits but for whatever reason it is retrieved extremely slowly in some circumstances — I gave the example above of Immich thumbs which can take ages to ls -lR, but there are others. In any case I am OK with doing an experiment at under $70 delivered.
Just note that if you have a RAIDZ2 data pool, special vdevs can’t be removed after being added.
I do thumbs on a separate SSD pool entirely.
The data vdev is a mirror but this is a good reminder about limitations on device removal.
Yep. I know some people are sick of hearing me say it, but someone is reading it every time and going “well I’m sure glad I learned that before I put my data at risk” 
im getting permission errors when running this with cron and i dont think sudo is the trick here
You’re on SCALE/CE? It works fine for me as a Cron Job with TrueNAS Core.
In your Cron configuration, is there an option to run as the root user?
Are you running the cron job as user root?
Also it is generally recommended to use full path names in cron jobs like
/sbin/zpool trim ssd-pool; /sbin/zpool trim boot-pool
HTH,
Patrick
on ce. sorry i missed that i could change the user its run as. worked fine after setting to root.
ya i missed that option 
I promised I would update once I installed the special vdevs.
I bought 2x HGST enterprise 400GB SAS SSD pulled from decommissioned servers at >95% health. The cost was under USD $70 total delivered.
On TrueNAS nightly 2026-01-31 (for zfs 2.4.0) I built a new pool of 2x 12TB spinning disk mirror and the 2 SSD as special vdev mirror. It looks like this:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
697bc230-e597-4a56-ae8f-b197559b8117 ONLINE 0 0 0
cd2bbfa7-62ba-43ba-ad4f-e5aa116dea4a ONLINE 0 0 0
special
mirror-1 ONLINE 0 0 0
9197e740-5d78-440a-ad54-21af39e7d9e1 ONLINE 0 0 0
10b7b0ba-479e-4ed3-96d2-71a2174bda28 ONLINE 0 0 0
I also set special_small_blocks to 16M on these datasets to force all files onto the SSDs:
Data was migrated using cp -prv to ensure everything was rewritten.
Results:
This is so far the best performance improvement I have made at minimal cost on modest hardware. It’s relatively easy to do; creating the pool with special vdev was done all in the GUI, and I only had to pick out which datasets I wanted pinned to SSD with special_small_blocks. I’m very happy so far.
Warnings so far:
System config:
I will report back in a month or so to advise if I’m still happy. 