Learned something new - thank you
I did say not unless it is definitely needed and virtual disks/zvolumes/iscsi are all types of data that do need it.
However, a VM does NOT need to dump packet data into a zVolume virtual disk - it could dump it into a NFS share as normal ZFS files, and these wouldn’t need synchronous writes and should perhaps perform better even than with an SLOG. That said, if the the zVolume for the VM O/S is still on HDD then it might well still need an SLOG - or perhaps given that the virtual disk will now be substantially smaller the O/S itself could be on SSD without an SLOG because the ZIL writes will be the same speed.
TBH I am not really sure how much of this is science and how much hunches.
Seems like bad advice. For a start this means the system dataset becomes sync=never.
I’d advise to leave things as standard and install a SLOG if necessary.
If you really want to discard sync writes then set it in a per dataset basis.
It may indeed be bad advice - my idea is based only on theory and it gets trumped by even a microgram of experience that says it is needed - but if so, why?
Sync writes have such a huge overhead, even with SLOG to mitigate it, that you have got to be better off not doing sync writes at all if they aren’t needed.
For sequential writes of entire files (most NFS usage for example) it seems to me that you really don’t need sync writes to commit each partial write of the file - you just need fsync writes which are commits of the entire file at the end (and whilst they do use ZIL like sync writes, and so might still benefit from SLOG, you can’t turn them off). This is how SMB works, and NFS isn’t trying to achieve anything different.
Yes - for zVolumes and database files (and other virtual disks which exist as files rather zVols) than you need to commit each and every write and you need sync writes, but for sequential writes of entire files it doesn’t seem to me to be needed.
The apps pool / ixApps datasets might need sync writes if they have database access - and can you ever be certain that your pre-packaged app / docker image doesn’t include database writes? But then again, I would argue that apps and their active data should be on SSD anyway, and ZIL writes will be just as fast as SLOG on the same SSD whilst TXG writes will be faster.
AFAIK, disabling sync on a dataset will also disable fsync writes.
Ie all sync writes, including “fsync” is disabled.
The behavior you are describing is sync=standard
1 Like
I run VMs with sync disabled and rely on ZFS snapshots to save my bacon if/when it goes sideways. Could be an option if your daily delta isn’t huge…
Beauty might have the brains but stupid has the 
…
1 Like
I looked into this further and I was absolutely wrong. You should NOT use sync=disabled as standard.
3 Likes
Rebooted my TrueNAS box with Debian 12.9 and it shows the same 0’s as Scale. 
So some kind of Debian issue I guess?
Might I suggest an Intel Optane SLOG? You can get them pretty cheap in a M.2 form factor and they have basically infinite write endurance.
Optane just like any nvme will consume PCIe lanes. and if you are in a position to not worry about sync writes much, there is a good chance you would be using a consumer platform (or one based on it a la Xeon E) and don’t have PCIe lanes to spare on such things.
1 Like
Cheap Optane in M.2 slots is likely M10, which has limited bandwidth (x2) and endurance.
Optane DC P4801X exists in M.2 22110 form factor but is maybe not so cheap; given the choice here, go for U.2 or AIC for better cooling.
It might indeed be an upstream Debian issue.
If you can boot the 25.04-BETA system just to check the output of lsblk -D vs the smartctl commands to see if they don’t line up there.
If it’s still persisting there, it’s probably upstream in Debian. The reportbug command-line tool (from Debian, not TrueNAS) will probably be the best way to communicate directly with them.
I’ll give that a go next week after this SMR resilver is done. I have regrets about removing a drive to put it in another computer. 
OK, I have 25.04-Beta1 loaded up and things are interesting.
george@truenas42:~$ sudo lsblk -D /dev/sdg
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdg 0 4K 0B 0
└─sdg1 0 4K 0B 0
All the spinning drives show 4K now for Discard Granularity, both the SMR and the CMR drives.
Trim still won’t go for the SMR only array though, probably because the Discard Max is still 0.