The article glosses over the fact that fsync() itself has major issues. For example, on ext3, if you call fsync() on a single file, all file system cached data

The article glosses over the fact that fsync() itself has major issues. For example, on ext3, if you call fsync() on a single file, all file system cached data is written to disk, leading to an extreme slowdown. This led to a Firefox bug, when the sqlite db used for the awesome bar and for bookmarks called fsync() and slowed everything down. http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ http://shaver.off.net/diary/2008/05/25/fsyncers-and-curvebal... OS X does a fake fsync() if you call it with the defaults. https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html https://developer.apple.com/library/mac/#documentation/Cocoa... fsync in Mac OS X: Since in Mac OS X the fsync command does not make the guarantee that bytes are written, SQLite sends a F_FULLFSYNC request to the kernel to ensures that the bytes are actually written through to the drive platter. This causes the kernel to flush all buffers to the drives and causes the drives to flush their track caches. Without this, there is a significantly large window of time within which data will reside in volatile memory—and in the event of system failure you risk data corruption