That's not true. When a write is committed to the SLOG, it acknowledges back to the host immediately. If you've got disk contention on the back-end, the host will absolutely see faster write response until the point your memory is 3/8th full. If you do not have an SLOG, the system will not ack to the host until it has committed the TXG to disk on a sync write, meaning any disk contention will present itself as massive latency. With 768GB of memory and a 480GB SLOG in the system that is a LOT of outstanding transactions that could be buffered.

Sure if your workload is primarily long, sustained transactions the SLOG will do little. But for any workload that is even a little bursty in nature (like hosting virtual machines) it will absolutely make a difference.

All of the above is assuming you have enabled sync=always, which I hope people are doing for production workloads unless they happen to have an app that can tolerate lost writes/partial writes.

The ZIL is not a write-back cache. The ZIL is for maintaining integrity. The SLOG is for speeding up the ZIL.

As such it can behave a bit like a write-back cache as I mentioned in the linked post.

A crucial difference is that the ZIL is limited by the available memory regardless (and tunables, by default 5 seconds worth of data), which would not be the case for a write-back cache device.

I don't know why you keep responding by saying it's not a write-back cache.

1. I didn't ever call it a write-back cache and never even hinted at it operating like one

2. Write-back caching is only one of many options for write caches

Regardless of both of those points, the SLOG ABSOLUTELY will speed up writes if you have a bursty workload (like the virtual machines he's running) and sync=always enabled.

>A crucial difference is that the ZIL is limited by the available memory regardless (and tunables, by default 5 seconds worth of data), which would not be the case for a write-back cache device.

And yet that point is irrelevant to OPs question of whether or not SLOG was speeding up his writes, which it almost assuredly is doing with the amount of memory and the size of his SLOG device when he is doing sync writes.

Fair enough, I should have just called it cache.

The point remains though. The ZIL is not meant to be a cache. The SLOG (which is a "ZIL on a separate device") could be viewed as a cache, but it's a cache for the ZIL. Thus being a cache for writes is incidental, not the primary purpose.

Certainly, if your workload aligns with those conditions, then you will experience a performance boost. For other workloads it it won't help and for certain workloads it can even be detrimental[1].

[1]: https://www.reddit.com/r/zfs/comments/m6ydfv/performance_eff...