@T_Minus
here are more citations and while he has several verifies.. it checks with other articles I have read..
this is why solaris got to charge a fortune for zfs support.. people dont understand it.. some by design as sun didnt really tell people what was going on under the hood, and part due to the complexity and human nature of being lazy not wanting to do the reading and the research.. so people mostly dont use zfs correctly...
pasted from another source.. not mine...
The
ZIL (ZFS Intent Log) is basically a transaction log (similar to those in databases, if you're familiar).
Note that since ZIL contents are duplicated in RAM, and ZFS uses the RAM copy. Normal operation rarely reads contents from the ZIL - it is there for correctness and recovery, and read when importing.
It is not a write buffer as such, just there as a non-volatile copy of the RAM copy. Yet it is still important to IOPS, because it is flushed to disk regularly
The ZIL is used for all ZFS metadata.
The ZIL also applies to sync writes. (with some details: sync writes smaller than 64KB have their content go to the ZIL, larger writes go to the pool and are pointed to by the ZIL. That size is tweakable. This seems to be a sensible performance consideration that has little other impact?
(verify))
Non-sync write data skip the ZIL, they are only in RAM (typically a few-second cache
(verify)).
It also applies to all all filesystem syscalls that apply to ZFS. (Technically, this means that
all writes are mentioned in the ZIL
(verify), white the
data is only there for for (small) sync writes
(verify))
The upshot is if recovery (after a crash / power loss) loses more async writes than sync writes. Like any filesystem. Because it's a sensible bias.
Due to ZFS's copy-on-write nature you would just see and older version of the data. The ZIL is there in part so that "accepted into the ZIL" typically means "will be seen in the pool, be it now or a bit later".