From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 13:01:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B24F106564A for ; Sun, 7 Dec 2008 13:01:50 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E28BA8FC14 for ; Sun, 7 Dec 2008 13:01:49 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 141535D67; Sun, 7 Dec 2008 14:01:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JPA8lDxMGwEl; Sun, 7 Dec 2008 14:01:46 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 3DC895D65; Sun, 7 Dec 2008 14:01:46 +0100 (CET) Message-Id: <9668C184-9534-4F0F-B633-C807DAD8ED95@bsdunix.ch> From: Thomas Vogt To: Wes Morgan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 7 Dec 2008 14:01:45 +0100 References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081207113509.GA19385@hyperion.scode.org> X-Mailer: Apple Mail (2.929.2) Cc: =?ISO-8859-1?Q?Marius_N=FCnnerich?= , FreeBSD Current , Peter Schuller Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 13:01:50 -0000 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 Vogt