Date: Fri, 18 Apr 2003 12:46:23 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Fred Clift <fclift@verio.net> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3EA02BDF.7020306@potentialtech.com> In-Reply-To: <20030418101259.M49571-100000@vespa.dmz.orem.verio.net> References: <20030418101259.M49571-100000@vespa.dmz.orem.verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA02BDF.7020306>