PATCH: Forcible delaying of UFS (soft)updates

[Fred Clift]

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 at verio.net -- Remember: If brute
force doesn't work, you're just not using enough.