From owner-freebsd-current@FreeBSD.ORG  Thu Jul 26 14:01:14 2007
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 1FAE416A417;
	Thu, 26 Jul 2007 14:01:14 +0000 (UTC)
	(envelope-from craig@xfoil.gank.org)
Received: from ion.gank.org (ion.gank.org [69.55.238.164])
	by mx1.freebsd.org (Postfix) with ESMTP id 0689313C45D;
	Thu, 26 Jul 2007 14:01:13 +0000 (UTC)
	(envelope-from craig@xfoil.gank.org)
Received: by ion.gank.org (Postfix, from userid 1001)
	id C20431125D; Thu, 26 Jul 2007 09:01:13 -0500 (CDT)
Date: Thu, 26 Jul 2007 09:01:13 -0500
From: Craig Boston <craig@xfoil.gank.org>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Message-ID: <20070726140113.GA49713@nowhere>
References: <20070725234322.G33266@woozle.rinet.ru>
	<20070725222035.GA50522@nowhere>
	<20070726134231.GO12473@garage.freebsd.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070726134231.GO12473@garage.freebsd.pl>
User-Agent: Mutt/1.4.2.2i
Cc: Dmitry Morozovsky <marck@rinet.ru>, current@FreeBSD.org
Subject: Re: ZFS on a notebook/512M settings
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2007 14:01:14 -0000

On Thu, Jul 26, 2007 at 03:42:31PM +0200, Pawel Jakub Dawidek wrote:
> Let me explain what disabling ZIL really means. Once ZIL is disabled,
> fsync(2) is a no-op, ie. calling fsync(2) on a descriptor doesn't mean
> your data would be safely stored on disk at the time function returns.
> There is no data corruption for local use, only this fsync(2) problem.
> 
> "Data corruption" can happen from NFS client point of view, when your
> ZFS file system is exported over NFS and your NFS server crashes.

Does this increase the window after an fsync is performed that a crash
or power loss will lose recent changes?  That's what I got from reading
the descriptions of ZIL, perhaps "corruption" was a poor choice of
words.

Craig