PATCH: Forcible delaying of UFS (soft)updates

[Bill Vermillion]

Throwing caution to the wind and speaking without thinking about
what was being said on Sat, Apr 12, 2003 at 18:18 ,
Jon Hamilton blurted this:

> Bill Vermillion <bv at wjv.com>, said on Sat Apr 12, 2003 [02:53:46 PM]:
> } 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.  

> I agree, and that's what I said.  Unfortunately, I wasn't overly clear
> about it.  The optional behavior would be the _enabling_ of the patch
> behavior.

I feel better about it already :-)

Thanks for the clarification.

Bill
-- 
Bill Vermillion - bv @ wjv . com