From owner-freebsd-fs@FreeBSD.ORG Tue Apr 15 11:38:06 2003 Return-Path: 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 9778537B401; Tue, 15 Apr 2003 11:38:06 -0700 (PDT) Received: from mail.tel.fer.hr (zg03-155.dialin.iskon.hr [213.191.135.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E3543F85; Tue, 15 Apr 2003 11:38:04 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (marko-tp.katoda.net [192.168.201.109]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id h3FIa3xK000661; Tue, 15 Apr 2003 20:36:08 +0200 (CEST) (envelope-from zec@tel.fer.hr) Message-ID: <3E9C517B.6039679A@tel.fer.hr> Date: Tue, 15 Apr 2003 20:37:47 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kirk McKusick References: <200304130004.h3D04Vb5006635@beastie.mckusick.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 18:38:07 -0000 Kirk McKusick wrote: > 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. Tempted by a lot of opposition to the concept of (optionally) ignoring fsync() calls when running on battery power, I wonder what effect the concept of unconditional delaying of _all_ disk updates by ATA-disk firmware will make on FS consistency in case of system crash or power failure? I do not want to imply such a concept is a priori bad, however I fail to realize its advantages over OS-controlled delaying of disk synching. Marko