[zfs-discuss] ZIL waste of space?

Edward Ned Harvey (zfsonlinux) zfsonlinux at nedharvey.com
Mon Feb 5 13:54:07 EST 2018

> From: zfs-discuss [mailto:zfs-discuss-bounces at list.zfsonlinux.org] On Behalf
> Of Bryn Hughes via zfs-discuss
>  From the data I've seen go by on the list repeatedly, you won't actually see
> CORRUPTION, you just may be missing a few seconds worth of
> transactions.  Even with sync=disabled ZFS will honor write barriers, meaning
> a particular batch of transactions are either committed or they aren't.
> "Corruption" implies "data randomly destroyed", while the reality is you may
> simply be back in time a few transactions.  Many workloads are perfectly fine
> with this scenario.

Almost correct.

ZFS itself does not experience corruption, so if a standalone zfs server crashes and comes back up, the pool is guaranteed to be in a valid state through which the pool previously was known to pass through. You may lose up to 5 sec of the latest writes, but you will not have an inconsistent state or some other type of corruption. However...

If a network client tells a ZFS server to write something (NFS or ISCSI for example) and the ZFS server tells a lie by buffering that data and acknowledging "has been flushed to nonvolatile storage," (which is what sync=disabled does), and then ZFS crashes before it actually hits nonvolatile storage, and then ZFS comes back up and restores NFS or ISCSI service... Then the client may think data has been flushed which actually was lost. The guest OSes in vmware are then inconsistent, and prone to corruption. Hence all that stuff I wrote in the previous message... You can set sync=disabled if you can guarantee an ungracefully crashed ZFS server will not come up and restore service to clients, without restarting all the clients whose state depends on it. This is actually very attractive for use cases where it's acceptable (usually is acceptable in home usage) because it has zero cost and maximum performance.

More information about the zfs-discuss mailing list