From owner-freebsd-fs@FreeBSD.ORG  Sun Apr 13 10:55:10 2003
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4FD9837B405; Sun, 13 Apr 2003 10:55:09 -0700 (PDT)
Received: from chez.McKusick.COM (chez.mckusick.com [209.31.233.177])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id CBF0643F93; Sun, 13 Apr 2003 10:55:07 -0700 (PDT)
	(envelope-from mckusick@mckusick.com)
Received: from beastie.mckusick.com (localhost [127.0.0.1])
	by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h3D04Vb5006635;
	Sat, 12 Apr 2003 17:04:32 -0700 (PDT)
	(envelope-from mckusick@beastie.mckusick.com)
Message-Id: <200304130004.h3D04Vb5006635@beastie.mckusick.com>
To: Marko Zec <zec@tel.fer.hr>
In-Reply-To: Your message of "Sat, 12 Apr 2003 03:41:17 +0200."
             <3E976EBD.C3E66EF8@tel.fer.hr> 
Date: Sat, 12 Apr 2003 17:04:31 -0700
From: Kirk McKusick <mckusick@mckusick.com>
cc: freebsd-fs@freebsd.org
cc: freebsd-stable@freebsd.org
Subject: Re: PATCH: Forcible delaying of UFS (soft)updates 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Apr 2003 17:55:10 -0000

I am of the opinion that fsync should work. Applications like
`vi' use fsync to ensure that the write of the new file is on
stable store before removing the old copy. If that semantic
is broken, it would be possible to have neither the old nor
the new copy of your file after a crash. I do not consider
that acceptable behavior. Further, the fsync call is used
to ensure that link/unlink/rename have been completed. So
more than just fsync is being affected by your change. Lastly,
I often write out a file when I am about to suspend my laptop
(for low battery or other reasons) and I really want that file
on the disk now. I do not want to have to wait for it to decide
at some future time to spin up the disk.

I suggest that you make the disabling of fsync a separate
option from the rest of your change so that people can
decide for themselves whether they want partial savings
with working semantics, or greater savings with broken
semantics. I am also intrigued by the changes proposed by
Ian Dowse that may better accomplish the same goals with
less breakage.

	Kirk McKusick