PATCH: Forcible delaying of UFS (soft)updates

[Bill Moran]

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