>> I'm not really happy with this.  IMHO this should be the default
>> behavior of fsync(). A programmer using fsync in his software uses
>> it to make use data is on stable storage.

I agree.  This is (and always has been, as far as I can recall)
fsync()'s contract.

> The problem is that syncing 1K of data from one file could cause an
> entire 8MB cache to be written back (in fact, on an IDE disk, *will*
> cause that).  Some applications "defensively" call fsync on every
> write; think what that will do to overall system performance.

So, an application that is excessively conservative can interact with
hardware which has insufficiently powerful interfaces to produce bad
performance.  This is nothing new, nor do I see it as a problem.  If
I'd been aware that fsync() had been violating its interface contract
by just pushing data to volatile drive caches before this discussion, I
would have filed a bug report for it.

Nor do I see any alternative, given a drive with no cache flush
granularity better than all-or-nothing.  Except for violating fsync()'s
interface contract.

If you really want to provide a sysctl, or perhaps a mount option, that
tells the kernel "consider drive cache "stable storage" for fsync()
purposes", people who prefer to get the wrong answers quickly (to steal
a phrase from K&P, I think it is, that actually isn't quite
appropriate) can use it....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B