From owner-freebsd-fs@FreeBSD.ORG Fri Sep 17 16:42:34 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 563BF106564A for ; Fri, 17 Sep 2010 16:42:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id F28FF8FC14 for ; Fri, 17 Sep 2010 16:42:33 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id 7o8s1f0070QuhwU51siah6; Fri, 17 Sep 2010 16:42:34 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.westchester.pa.mail.comcast.net with comcast id 7sdZ1f00B3LrwQ23NsdZk5; Fri, 17 Sep 2010 16:37:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 097609B427; Fri, 17 Sep 2010 09:37:32 -0700 (PDT) Date: Fri, 17 Sep 2010 09:37:32 -0700 From: Jeremy Chadwick To: Freddie Cash Message-ID: <20100917163732.GA59537@icarus.home.lan> References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: Fri, 17 Sep 2010 16:42:34 -0000 On Fri, Sep 17, 2010 at 09:21:54AM -0700, Freddie Cash wrote: > On Fri, Sep 17, 2010 at 9:18 AM, Jeremy Chadwick > wrote: > > On Fri, Sep 17, 2010 at 09:17:11AM -0700, Freddie Cash wrote: > >> On Fri, Sep 17, 2010 at 8:35 AM, Gil Vidals wrote: > >> > Bryan thank you for the detailed answer. > >> > > >> > Assuming the ZIL SSD died, what steps would I follow to recover the pool? (i > >> > hope it is recoverable). > >> > >> If you are running ZFSv1 through ZFSv18 and your log device dies, your > >> pool is dead, gone, unrecoverable, no secret prize, no continues, do > >> not pass go, etc, etc, etc. > >> > >> If you are running ZFSv19 or newer and your log device dies, you can > >> remove the dead device and carry on.  You will lose any data that was > >> in the ZIL, but the pool will be intact. > > > > Given the severity of this predicament, then why is it people are > > disabling the ZIL (via vfs.zfs.zil_disable=1) ? > > I'm not sure what you mean by that. > > 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?) You can search the FreeBSD lists for people continually advocating vfs.zfs.zil_disable=1. There's even a couple blog posts from engineers talking about how the only way to get their filers to behave decently was to disable the ZIL[1][2][3]. In most (every?) cases I've seen where someone advocates disabling the ZIL, pool details aren't provided, which leads me to believe their pools have no "log" devices. Here's a better way to phrase my question: does vfs.zfs.zil_disable=1 do anything if there aren't any "log" devices in use (in any pool)? [1]: http://jmlittle.blogspot.com/2010/03/zfs-log-devices-review-of-ddrdrive-x1.html [2]: http://blogs.sun.com/erickustarz/entry/zil_disable [3]: http://weblog.etherized.com/posts/130 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |