From owner-freebsd-fs@FreeBSD.ORG Fri Apr 18 09:24:38 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 63CEE37B405; Fri, 18 Apr 2003 09:24:38 -0700 (PDT) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACEC543FB1; Fri, 18 Apr 2003 09:24:36 -0700 (PDT) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.oremut01.us.wh.verio.net (Postfix) with ESMTP id F27713BF437; Fri, 18 Apr 2003 10:24:35 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h3IGOZJ30971; Fri, 18 Apr 2003 10:24:35 -0600 (MDT) Date: Fri, 18 Apr 2003 10:28:24 -0600 (MDT) From: Fred Clift X-X-Sender: To: David Schultz In-Reply-To: <20030418124914.GA10979@HAL9000.homeunix.com> Message-ID: <20030418101259.M49571-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Fri, 18 Apr 2003 16:24:38 -0000 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.) Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough.