Disks lie. And the controllers that run them are partners in crime.

Re:Disks lie. And the controllers that run them are partners... by recoiledsnake on Friday September 07, 2012 @10:00PM (#4491961)

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

OS X does a fake fsync() if you call it with the defaults. 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

[ Parent | on HN ]

Re:Disks lie. And the controllers that run them are partners... by btrask on Saturday September 08, 2012 @11:23AM (#4493102)

  So in summary, I believe that the comments in the MySQL news posting
  are slightly confused.  On MacOS X fsync() behaves the same as it does
  on all Unices.  That's not good enough if you really care about data
  integrity and so we also provide the F_FULLFSYNC fcntl.  As far as I
  know, MacOS X is the only OS to provide this feature for apps that
  need to truly guarantee their data is on disk.

The full post goes into detail. http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072...

[ Parent | on HN ]