> > Adding a flag to fsync() to make it do what we expect from it, just because
> > some application don't use it in a good way seems backward to me.
> 
> But how do we know it won't do what we expect? Some disks have the write 
> cache battery-backed, so it is as good as disk. Some disks will have the 
> cache off. Some disks will have the disk on, but be in a battery-backed 
> enclosure, so that the cache is safe even though it looks unsafe.
> 
> Knowing what's "safe" is a local policy decision. I think we should leave 
> it that way.

I agree that it should be a local policy decision.  That means the local
policy maker needs (a) full information on which to base the decision,
and (b) a knob by which to enforce the decision - one that does not
require recompiling apps for which source may not be available to add
flags to standard API calls to make them do what standard API says.
I don't object to having such flags available for new development--even
having two flags so the program can explicitly require either the
conservative or the fast'n'loose behavior, or accept the default set by
the local policy maker using the knob.  A sysctl knob, a per-mountpoint
knob, or a per-application knob perhaps implementable with systrace
without modifying the app, could all be worth considering.  Maybe
systrace already provides such an ability without extra work.  Then
requirement (a) demands that the fsync man pages explicitly discuss
the caching issue, describe how to set the applicable knobs, and
explain under what assumptions of drive/controller/power-supply
capability the different knob settings make sense.

-Chap