PATCH: Forcible delaying of UFS (soft)updates

[Bill Vermillion]

In the last exciting episode of the Jon Hamilton saga 
on Sat, Apr 12, 2003 at 12:24 , Jon Hamilton as heard to say:

> Dave Hart <davehart at davehart.com>, said on Sat Apr 12, 2003 [04:58:13 PM]:
> } Marko Zec said:
> [...]
> } > If the disk would start spinning every now and than,
> } > the whole patch would than become pointless...

> } As I feared.

> } > [...] the fact that the modified fsync() just returns 
> } > without doing anything useful doesn't mean the data will be
> } > lost - it will  simply be delayed until the next coalesced
> } > updating occurs.

> } Unless, of course, your system or power happens to fail.
> } Imagine you have a database program keeping track of banking
> } transactions.  This program uses fsync() to ensure its
> } transaction logs are committed to reliable storage before
> } indicating the transaction is completed.  Suppose the moment
> } after I withdraw $500 from an ATM, the operating system or
> } hardware fails at the bank.

> Right.  So in such a situation, the admin for that system would not 
> enable this optional behavior.  There probably aren't too many cases
> where mission critical financial transaction systems run on a laptop
> on which the desire is maximal battery life, which is the case from
> which this whole patch/discussion derives.  It's a conscious tradeoff.

I think 'the admin could enable this optional behaviour' is the
wrong approach.

I think it should be for laptops the admin could >disable< the
feature.  By default make everyting as robust and failsafe as
possible.  

In the past enable options aren't always enabled when they should
be.  Default to secure and stable and let the admins change it.

Bill
-- 
Bill Vermillion - bv @ wjv . com