sync is a standard system call in the Unix operating system, which commits to disk all data in the kernel filesystem buffers, i.e., data which has been scheduled for writing via low-level I/O system calls. Note that higher-level I/O layers such as stdio may maintain separate buffers of their own.
As a function in C, the sync() call is typically declared as void sync(void) in <unistd.h>. The system call is also available via a command line utility also called sync, and similarly named functions in other languages such as Perl.
The related system call fsync commits just the buffered data relating to a specified file descriptor.[1] fdatasync is also available to write out just the changes made to the data in the file, and not necessarily the file's related metadata.[2]
Unix systems typically run some kind of flush or update daemon, which calls the sync function on a regular basis. On some systems, the cron daemon does this, and on Linux it's handled by the pdflush daemon.[3] Buffers are also flushed when filesystems are unmounted or remounted read-only, for example prior to system shutdown.
In order to provide proper durability, databases need to use some form of sync in order to make sure the information written has made it to Non-volatile storage rather than just being stored in a memory-based write cache that would be lost if power failed. PostgreSQL for example uses a variety of different sync calls, including fsync and fdatasync, in order for commits to be durable.[4] Unfortunately, for any single client writing a series of records, a rotating hard drive can only commit once per rotation, which makes for at best a few hundred such commits per second.[5] Turning off the fsync requirement can therefore greatly improve commit performance, but at the expense of potentially introducing database corruption after a crash.
Databases also employ log files (typically much smaller than the main data files) that have information about recent changes, such that changes can be reliably redone in case of crash; then the main data files can be synced less often.
Hard disks may default to using their own volatile write cache to buffer writes, which greatly improves performance while introducing a potential for lost writes.[6] The performance impact of turning caching off is so large that even the normally conservative FreeBSD community rejected disabling write caching by default in FreeBSD 4.3.[7]
fsync has been found to slow down performance of Firefox 3.0; the call was introduced in order to guarantee the integrity of the embedded sqlite database.[8] Linux Foundation Chief technical officer Theodore Ts'o claims there is no need to "fear fsync".[9]
libnofsync is a hack that replaces fsync with a dummy function that does nothing.