Just adding more notes on that by reactivating one of haypo's
links from #8604.  (And: maybe some Linux documentation should be
updated?)  From Theodore Ts'o,
http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don’t-fear-fsync:

    As the Eat My Data presentation points out very clearly, the only
    safe way according that POSIX allows for requesting data written
    to a particular file descriptor be safely stored on stable storage
    is via the fsync() call.  Linux’s close(2) man page makes this
    point very clearly:

    A successful close does not guarantee that the data has been
    successfully saved to disk, as the kernel defers writes. It is not
    common for a file system to flush the buffers when the stream is
    closed. If you need to be sure that the data is physically stored
    use fsync(2).

    Why don’t application programmers follow these sage words?  These
    three reasons are most often given as excuses:

    - (Perceived) performance problems with fsync()
    - The application only needs atomicity, but not durability
    - The fsync() causing the hard drive to spin up unnecessarily in
      laptop_mode

(Don't ask me why i'm adding this note though.
I should have searched for it once i've opened that issue?
Bah!!!  Ts'o did not write that article for me.  He'd better hacked.)