What ZIL metrics are exposed by (Open)ZFS on Linux(utcc.utoronto.ca)
utcc.utoronto.ca
What ZIL metrics are exposed by (Open)ZFS on Linux
https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSGlobalZILInformation
1 comments
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.
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.)
(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.)
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.
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.