homepage

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.)