From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 16:10:29 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 AE45B1065672 for ; Thu, 23 Sep 2010 16:10:29 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2A3518FC1B for ; Thu, 23 Sep 2010 16:10:28 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX18mTwGPvtlEXpfWrM7U4x30r/eg3B5PS6w@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id o8NGAQsR013309; Thu, 23 Sep 2010 17:10:26 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o8NGAPA2018901; Thu, 23 Sep 2010 17:10:25 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o8NGAPkf018898; Thu, 23 Sep 2010 17:10:25 +0100 Date: Thu, 23 Sep 2010 17:10:25 +0100 Message-Id: <201009231610.o8NGAPkf018898@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: (message from David Brodbeck on Wed, 22 Sep 2010 10:19:22 -0700) References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> <201009221300.o8MD0Cbm030033@higson.cam.lispworks.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Thu, 23 Sep 2010 16:10:29 -0000 >>>>> On Wed, 22 Sep 2010 10:19:22 -0700, David Brodbeck said: > > On Wed, Sep 22, 2010 at 10:14 AM, David Brodbeck wrote: > > On Wed, Sep 22, 2010 at 6:00 AM, Martin Simmons wrote: > >>>>>>> On Tue, 21 Sep 2010 15:38:22 -0700, David Brodbeck said: > >>> > >>> 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. > >> > >> Is that true for all versions of NFS?  In my experience (on 8.0-RELEASE), > >> NFSv2 is indeed synchronous, but NFSv3 does asynchronous flushing (for a > >> variety of different client OSes). > > > > It does allow clients to request asynchronous flushing.  My statement > > that "essentially every write is synchronous" was a bit of an > > overstatement; the problem comes when the client issues a COMMIT, > > which happens frequently when doing some operations, such as > > extracting tar files.  These are the operations that can get quite > > slow when using NFS with the ZIL enabled and no separate log device. > > By "quite slow," I mean several minutes to extract a tar file that > > takes less than a minute with the ZIL disabled. > > I should add that there's a very good, if somewhat > OpenSolaris-centric, explanation of the issue here: > http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine > > The problem shows up more with ZFS because it enforces proper cache > semantics, while many other filesystems do not. This isn't always a > satisfactory explanation to users who expect to be able to untar files > in a reasonable amount of time, however. ;) Thanks, I see what you mean. FWIW, both Linux and FreeBSD 7.3 nfs clients appear to be running asynchronously by default (zpool iostat 1 shows bursty writes while extracting with tar), whereas Solaris 10 clients appear to be doing very slow synchronous operations. __Martin