From owner-freebsd-fs@FreeBSD.ORG Fri Apr 18 09:46:26 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 22FA537B405; Fri, 18 Apr 2003 09:46:26 -0700 (PDT) Received: from pa-plum1b-166.pit.adelphia.net (pa-plum1b-122.pit.adelphia.net [24.53.161.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EECF43FCB; Fri, 18 Apr 2003 09:46:25 -0700 (PDT) (envelope-from wmoran@potentialtech.com) Received: from potentialtech.com (working [172.16.0.95]) h3IGkNwl000376; Fri, 18 Apr 2003 12:46:24 -0400 (EDT) (envelope-from wmoran@potentialtech.com) Message-ID: <3EA02BDF.7020306@potentialtech.com> Date: Fri, 18 Apr 2003 12:46:23 -0400 From: Bill Moran User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030301 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Clift References: <20030418101259.M49571-100000@vespa.dmz.orem.verio.net> In-Reply-To: <20030418101259.M49571-100000@vespa.dmz.orem.verio.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org cc: David Schultz 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: Fri, 18 Apr 2003 16:46:26 -0000 Fred Clift wrote: > On Fri, 18 Apr 2003, David Schultz wrote: > >>explicitly tells it to IDLE IMMEDIATE at the appropriate time. >>But being exact about this isn't particularly important. > > I think it might be nice to have something like this that immediately > spins the disk down after the burst of writes - though, if I remember > correctly, keeping a disk spinning takes far far less power than spinning > it up, so shutting down the disk 3 minutes earlier than you otherwise > might wont be that big of a power savings compared to avoiding spinning it > up so much. > >>As for the ATA delayed write feature, I don't believe it will >>guarantee consistency. This is true even if the drive doesn't > > There has been a lot of talk on this thread about how the > (not-enabled-by-default) fsync portion of this patch violates the 'fsync > contract' and violates guarantees of consistency. As was stated by the > creator of the patch, this is intented to only be used in situations where > it is relatively 'unimportant' to have these guarantees. His typical > usage is on a non-mission-critical machine (his laptop) that doesn't > contain data which, _when_lost_, isn't going to be irreplaceable. > > There have been many objections about various databases not getting > updates, qmail/sendmail loosing mail, vi removing/overwirting a file, etc, > but aparently these are not the cases for which this patch was designed. > If a person cared about these possiblities, he wouldn't turn this > functionality on. > > If on the other hand, a person were stuck at the doctor's office waiting > room, with low battery, playing nethack, then perhaps this patch is just > what you want. > > Can we stop going on and on about how terrible this patch is for > 'important' and 'unrecoveralbe' data? This patch should not be used on > any machine that has irreplacable data. If I were using this on my laptop > working on code and I LOST my changes, I can always cvs update to get the > file back and start working again, having lost 30 minutes of work. Of > course my laptop doesn't get major mission-critical use either... > > On the other hand _if_ the patch could be slightly modified to still > guarantee fsync semantics (when qmail writes mail, vi overwrites a file, > or mysql updates a table, etc) so that data would be safer, but not > significantly degrade the utility of the patch then I'd say lets 1) make > the small change (ie disk spin-up/write/spin-down on every fsync? will > this take more power than it is worth?) and 2) incorperate this into > FreeBSD and let people get on with using it!. (It doesn't have to be > commited into the tree to get use, but it certainly would get much more > use this way.) I've been following this thread for a while out of curiosity. I understand the dangers of suicical fsync, and I understand the benefits. I know this isn't normally the kind of thing that should get said on these lists, but if anyone is taking a vote, I agree with Fred 100%. Include the functionality, document the dangers, and leave it off by default. Despite the hundred-billion places where it would be a bad idea, I feel there are a number of places where it would be helpful. -- Bill Moran Potential Technologies http://www.potentialtech.com