Steffen Daode Nurpmeso <sdao...@googlemail.com> added the comment:
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.)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
