From owner-freebsd-fs@FreeBSD.ORG Sat Sep 18 15:48:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5360D106566C for ; Sat, 18 Sep 2010 15:48:19 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id EAF3F8FC20 for ; Sat, 18 Sep 2010 15:48:18 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o8IFNtln028051; Sat, 18 Sep 2010 10:23:56 -0500 (CDT) Date: Sat, 18 Sep 2010 10:23:55 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Jeremy Chadwick In-Reply-To: <20100917163732.GA59537@icarus.home.lan> Message-ID: References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> <20100917163732.GA59537@icarus.home.lan> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sat, 18 Sep 2010 10:23:56 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: what happens to pool if ZIL dies on ZFS v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 15:48:19 -0000 On Fri, 17 Sep 2010, Jeremy Chadwick wrote: >> >> This (dead ZIL == dead pool) only applies to separate log (slog) devices. > > I was under the impression ZFS still managed to utilise the ZIL when a > pool didn't have any "log" devices associated with it (possibly some > sort of statically-allocated amount of RAM?) To clarify, the ZIL (ZFS Intent Log) is a non-volatile log of pending (uncomitted) synchronous write requests. ZFS always has one. A synchronous write does not return until the data is at least written into the ZIL. If you "disable ZIL" then you are pretending that synchronous writes were immediately written (even when they were not). This will not endanger your pool, but recently requested synchronous writes may be lost (just as recent asyncronous writes may be lost) if the system loses power, or spontaneously reboots. By default, ZFS will buffer up to 30 seconds of writes (async + sync) and in fact zfs writes are coherent so that synchronous writes are treated the same as asynchronous writes. The only difference is that when a synchronous write completes, it is cleared from the ZIL. The ZIL is used to replay buffered synchronous writes which did not complete prior to a system crash or unexpected reboot. The 30 seconds of buffering only occurs on systems with a very large amount of RAM and/or a relatively slow write rate. Otherwise, zfs will write data much more often. If a system has limited RAM, then it will also buffer less data in the ZIL since it needs to write more often. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/