From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 22:38:23 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 E2CCC1065673 for ; Tue, 21 Sep 2010 22:38:23 +0000 (UTC) (envelope-from gull@gull.us) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE858FC18 for ; Tue, 21 Sep 2010 22:38:23 +0000 (UTC) Received: by eyx24 with SMTP id 24so2658130eyx.13 for ; Tue, 21 Sep 2010 15:38:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.16.207 with SMTP id p15mr4801280eba.61.1285108702292; Tue, 21 Sep 2010 15:38:22 -0700 (PDT) Received: by 10.14.29.76 with HTTP; Tue, 21 Sep 2010 15:38:22 -0700 (PDT) X-Originating-IP: [69.91.158.134] In-Reply-To: <20100917161847.GA58503@icarus.home.lan> References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> Date: Tue, 21 Sep 2010 15:38:22 -0700 Message-ID: From: David Brodbeck To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 21 Sep 2010 22:38:24 -0000 On Fri, Sep 17, 2010 at 9:18 AM, Jeremy Chadwick wrote: > Given the severity of this predicament, then why is it people are > disabling the ZIL (via vfs.zfs.zil_disable=1) ? If you don't have a separate log device, synchronous writes are very slow with the ZIL enabled. This isn't such a big deal unless you're using NFS, where essentially every write is synchronous. Then many common operations become conspicuously slow, especially compared to Linux, which isn't as fastidious about requiring data to be flushed all the way to the platters before signaling to NFS clients that the operation is complete. The danger in this case isn't that the pool could be damaged, but that a server crash could result in data not being written to disk even though the client believes the operation completed successfully; essentially, this would be silent data loss, since NFS server reboots are supposed to be invisible to client applications.