If I understand right, even with a SLOG device data is always written directly to the vdevs, and the SLOG unit is written like a "transaction log" ?
So no data is on SLOG or ZIL ?
Nevertheless this improves write performance ?
No, please re-read the second paragraph of the linked message. The ZIL is the ZFS intent log, which is just a list of things ZFS intends to do to the pool. The storage pool is only infrequently updated, once every few seconds, potentially with HUGE amounts of data, all neatly aggregated into a single transaction group.
You don't, bluntly, sorry
even with a SLOG device data is always written directly to the vdevs,
vdevs don't meaningfully enter into this. vdevs build your pool. Worry about the pool. Stored data is not written directly to the pool, and instead gets aggregated into a transaction group in RAM. That'd be bad for sync writes since the filesystem is promising that those writes have been committed to stable storage. The ZIL handles that problem, but usually ZIL performance sucks, so then we pull the ZIL out and put it on a separate way-fast device we call a SLOG.
and the SLOG unit is written like a "transaction log" ?
We say intent log. A ZFS transaction is something else.
So no data is on SLOG or ZIL ?
The data in the ZIL is whatever data has not been committed to the pool as part of a transaction group. This is true whether you're using the in-pool ZIL or a separate SLOG device.
Nevertheless this improves write performance ?
No, sync write performance is usually suckier than standard write performance. You have a few options.
1) Lie about sync writes (ignore them): this is the only thing that's approximately as fast as standard write performance.
2) Do sync writes to the pool like a traditional filesystem. With ZFS this is untenable because it'd force a transaction group to be processed. Total non-starter.
3) Cheat by setting apart a section of the pool to make temporary notes about what you've promised to consumers. We call this a ZIL. Writes to the ZIL do not go through the transaction group process and happen synchronously. Performance is terrible but promises are kept.
4) Cheat on the solution in 3) by pulling that out of pool and putting it on a separate log (SLOG) device. This can be much faster than 3) but isn't faster than 1).[/QUOTE][/QUOTE]
