HEADS UP: New ZFS in the tree.

Thomas Vogt freebsdlists at bsdunix.ch
Sun Dec 7 05:01:50 PST 2008


Am 07.12.2008 um 13:41 schrieb Wes Morgan:
> On Sun, 7 Dec 2008, Peter Schuller wrote:
>>> While you are talking about it: Does anyone know if the fsync blocks
>>> until the data is really stable on the device or if it simply  
>>> returns
>>> when ZIL is disabled?
>>> In my understanding the topmost block would need to be written for  
>>> the
>>> "commit" to be on disk.
>> My understanding is that disabling the ZIL *will* break the semantics
>> of fsync().
>> The claim of "always consistent on disk" is not violated and is still
>> maintained, since consistency refers to ZFS' internal consistency.
>> The tuning guide someone posts a link to later in this thread has
>> specific claims about this IIRC; such as NFS breaking (because
>> fsync-on-close semantics mandated by NFS, among other things, will  
>> not
>> be honored).
> And this would also apply to databases that rely on fsync() for ACID  
> compliance, such as postgres, right?


I do not recomment to disable ZIL in general. In my case it's just a  
workaround to get rid of deadlocks on my -CURRENT server (many  
rsync,http and ftp processes).

It's also common to disable ZIL for better NFS performance but as  
Peter mentioned it has some drawbacks.

Read: http://blogs.sun.com/erickustarz/entry/zil_disable it explains  
some drawbacks for fsync() and NFS.

Disabling the ZIL can cause corruption for NFS clients in the case  
where a reply to the client is done before the server crashes, and the  
server crashes before the data is commited to stable storage. If you  
can't live with this, then don't turn off the ZIL.

Thomas Vogt

More information about the freebsd-current mailing list