Hello 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? Yes. 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. Quote: 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. Regrads, Thomas VogtReceived on Sun Dec 07 2008 - 12:01:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC