From owner-freebsd-fs@FreeBSD.ORG Sun May 1 16:32:39 2011 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 257B51065679 for ; Sun, 1 May 2011 16:32:39 +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 DEB198FC17 for ; Sun, 1 May 2011 16:32:38 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id p41GWXeu024710; Sun, 1 May 2011 11:32:33 -0500 (CDT) Date: Sun, 1 May 2011 11:32:33 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Rick Macklem In-Reply-To: <640208384.682241.1303948694525.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <640208384.682241.1303948694525.JavaMail.root@erie.cs.uoguelph.ca> 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]); Sun, 01 May 2011 11:32:34 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: make the experimental NFS subsystem the default one 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: Sun, 01 May 2011 16:32:39 -0000 On Wed, 27 Apr 2011, Rick Macklem wrote: > > I don't know anything about ZFS, but I would think that, if you see a > major performance improvement, that ZFS isn't committing stuff to logs > so that data won't be lost. > > Maybe the ZFS folks can comment? (I don't remember seeing the details > of what you change? If you sent a patch, sorry, but I've misplaced it.) Zfs will loose as much as 5 seconds worth of data (and maybe even 10 seconds) if the data is written slowly and/or the server has quite a lot of RAM. It commits data in order so the written data will be completely coherent for that snapshot in time, but the result may still be completely corrupted from the client's perspective. 5 (or 10!) seconds of data could be quite a lot of data, and could represent entire new directory trees, or large directory trees which were removed. Individual file content could be overwritten hundreds of times before the point where the server arbitrarily decides to commit it. If the server bounces, its data won't match what the client thinks it should have. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/