4 ms·

This appears to be benchmark gaming - the POSIX Rationale for fsync(2) says: The fsync() function is intended to force a physical write of data from the buffer

by caf 13y ago

This appears to be benchmark gaming - the POSIX Rationale for fsync(2) says: The fsync() function is intended to force a physical write of data from the buffer cache, and to assure that after a system crash or other failure that all data up to the time of the fsync() call is recorded on the disk. Since the concepts of "buffer cache", "system crash", "physical write", and "non-volatile storage" are not defined here, the wording has to be more abstract.

antirez 13y ago
In other words, what the osx default fsync() semantics is useful for? I had the same discussion on Twitter a few days ago...
- Someone 13y ago
  It is useful for forcing all writes out to the storage device. If you device is battery/UPS backed, has enough capacity to flush its buffers (to disk or to flash memory) after a power loss, that is sufficient to (eventually) get your data on disk (yes,the drive may fail, but if that happens after the data has hit the platter, you have no guarantees, either) From what I understand, that behaviour is in spec (for me, borderline, at best, but I don't make that spec) according to http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html http://pubs.opengroup.org/onlinepubs/009695399/functions/fsy... ("physical write from the buffer cache", not "physical write to the disk") and, AFAIK, is what others do, too (http://ridiculousfish.com/blog/posts/mystery.html http://ridiculousfish.com/blog/posts/mystery.html) Edit: http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072..., referenced from that ridiculous fish post, gives more background info.
  - antirez 13y ago
    Ok makes sense in special cases indeed, however a really unsafe default...
rsynnott 13y ago
Unfortunately, it's often not that simple on POSIX systems; it's quite common for disk controllers to disobey fsync, for instance, either in their drivers or in their hardware caches or both. I'm actually surprised Apple is even willing to make the guarantees above about F_FULLFSYNC; I'd read it as, at best, only applying to Apple hardware, as if a third-party controller is doing something silly they can't really do much about that.

by caf 13y ago

antirez 13y ago

In other words, what the osx default fsync() semantics is useful for? I had the same discussion on Twitter a few days ago...

Someone 13y ago
It is useful for forcing all writes out to the storage device. If you device is battery/UPS backed, has enough capacity to flush its buffers (to disk or to flash memory) after a power loss, that is sufficient to (eventually) get your data on disk (yes,the drive may fail, but if that happens after the data has hit the platter, you have no guarantees, either) From what I understand, that behaviour is in spec (for me, borderline, at best, but I don't make that spec) according to http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html http://pubs.opengroup.org/onlinepubs/009695399/functions/fsy... ("physical write from the buffer cache", not "physical write to the disk") and, AFAIK, is what others do, too (http://ridiculousfish.com/blog/posts/mystery.html http://ridiculousfish.com/blog/posts/mystery.html) Edit: http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072..., referenced from that ridiculous fish post, gives more background info.
- antirez 13y ago
  Ok makes sense in special cases indeed, however a really unsafe default...

rsynnott 13y ago

Unfortunately, it's often not that simple on POSIX systems; it's quite common for disk controllers to disobey fsync, for instance, either in their drivers or in their hardware caches or both. I'm actually surprised Apple is even willing to make the guarantees above about F_FULLFSYNC; I'd read it as, at best, only applying to Apple hardware, as if a third-party controller is doing something silly they can't really do much about that.