That's a strawman argument: The choice is not between "good enough
fsync" and full use of barriers / write-through caching, at all.
It is clearly possible to implement an fsync(2) that causes FLUSH CACHE
to be issued, without adding full barrier support to a filesystem. It
is likely doable to avoid touching per-filesystem code at all, if we
issue the flush from a generic fsync(2) code path in the kernel.
Thus, you have a "third way": fsync(2) gives the guarantee it is
supposed to, but you do not take the full performance hit of
Remember, fsync(2) means that the user _expects_ a performance hit.
And they took the extra step to call fsync(2) because they want a
guarantee, not a lie.