Nice overview. I added a separate ZIL sevice (SLOG) back in the day as back then writing the ZIL directly to the pool could fragment the pool. That has been changed somewhat recently, so now there's a dedicated area in the pool for the ZIL, thus it can no longer cause fragmentation.

Since I have primarily async workloads (fileshare) I was considering removing the SLOG but was curious what the impact might be. Seems the stuff in the article should give me tge details I've been looking for.

We'd also be curious to hear if you have a use case where you were using slog to mitigate something other than "sync write performance" and embedded log works worse.

I remember being surprised to learn a while back that all writes over NFS were treated as sync, so putting a ZIL on an Optane (for example) helped with NFS performance enormously.

This would have been on FreeBSD, I don't know if the same is still true, or true on ZoL.

NFS v2 writes are all synchronous. NFS v3 added an option to make them asynchronous, along with an additional 'COMMIT' NFS operation that flushes them to storage. In theory how it works is an NFS v3 client sends some number of async writes, holding a copy of their data in its own memory, and then sends a COMMIT to flush them all. If the NFS server replies to the COMMIT with an error, the NFS client has to re-send those async writes and their data (possibly as sync writes this time around); otherwise, it can discard its copy of the written data. NFS v3 clients can still decide to send sync writes if they don't want to keep track of all of this on their end for some reason (including low memory to hold the write data locally). And an NFS v3 server can opt to immediately write out theoretically 'async' writes for similar reasons. All of this is still true in NFS v4, with I think even more elaborations on the theme.

(I'm the author of the linked-to article and I have a long-standing interest in weird NFS behavior, since we operate NFS servers.)