> No, fsync is "Make sure the last write made it to disk. IN fact, force it out immediately. Also, all of the other pending writes as well, even if I'm not concerned about them. ..."

POSIX 1003.1 (2004) doesn't go so far as to require unrelated data to be committed (emphasis mine):

"The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes." (http://pubs.opengroup.org/onlinepubs/009695299/functions/fsy...)

I think there's a good argument that Linux and other workalike OSes go too far in flushing all dirty pages to disk when fsync() is called.

sync(), on the other hand, does require all dirty pages to be committed, though, ironically, it is permitted to return asynchronously (http://pubs.opengroup.org/onlinepubs/009695299/functions/syn...).

True, and it's good of you to clarify. However, what if the "other pending writes" are to the same file descriptor? Just because I'm eager to know when one write happens doesn't mean I care about other writes I made elsewhere.

sync() is basically a relic. Historically it only existed so that a UNIX userland process could roughly control the rate that dirty buffers went to disk. This was the "update" daemon historically, known as "fsflush" on SYSV. At least on linux that's internal to the kernel these days.

Isn't sync() still useful for making sure all file-systems are sync'ed (as by the bin/sync utility -- which apparently basically calls sync())? For instance before shutdown?

Occasionally helpful, yes. But in my experience, usually unnecessary. Filesystems will sync themselves prior to being unmounted, which takes care of most of the obvious sync usecases.