Thnak you for the answer Alain De Vos but I have read the forum post, it doesnt answer any of my inital questions.
In the forum link i can read that in ZIL is written "metadata" information no the data to be written to pool, is that correct?
In any way, if ZIL is written in pool disks why dont write data directly to pool disks?
Because then we would get many small writes and probably increase fragmentation.
For synchronous writes, speed is everything: we must get the data to disk immediately, so that the application can continue. But if we would write every little chunk right to its final destination, we would 1) need to keep track of all these destinations all the time, 2) often write chunks much smaller than the blocksize, 3) produce lots of disk seeks.
So instead we write some sufficient data to the ZIL immediately. This is a sequential file object, there is no allocation issue, no file-tree hierarchy and not so much additional seek. Then we collect the data for a while (specified by txg.timeout) to build a transaction group, and then finally push out that whole txg in one go. Some data may have been overwritten in the meantime, and now we don't need to write it multiple times. Some data may have accumulated to bigger chunks, and we can allocate these in one piece. And for mechanical disks we can line up the seeks in an optimal way.
"logs the intended transaction quickly to disk" its not quiclky, it is at the same speed as writting to pool directly as ZIL is a part of the pool disks if you dont use an external dedicated disk for SLOG.
Not really. When a file gets changed, the directory entry must also be rewritten (update the mtime and size). Since we have copy-on-write, we must in fact write that directory to a new location. That means, the index pointer to that location must also be rewritten, and so on up to the uberblock. Writing to a file in ZFS involves a bit more than just writing to the file.
The ZIL, in contrast, is just a sequential journal. Append the stuff to the end of it, and that's it.
You have a valid point nevertheless: writing to a ZIL
within the pool adds traffic to the pool, and it is usually seek activity between the current read position in the regular data and the write position at the end of the ZIL. This makes things slower when we have significant synchronous write activity. But if we would write to the final destination immediately, it would be worse.
