sync (Unix)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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.

[edit] Database use

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 may use 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.

[edit] Controversy

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", and that the real cause of Firefox 3 slowdown is the excessive use of fsync[9].

libnofsync is a hack that replaces fsync with a dummy function that does nothing.

[edit] References