Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

fsync(2) [linux man page]

FSYNC(2)						     Linux Programmer's Manual							  FSYNC(2)

NAME
fsync, fdatasync - synchronize a file's in-core state with storage device SYNOPSIS
#include <unistd.h> int fsync(int fd); int fdatasync(int fd); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): fsync(): _BSD_SOURCE || _XOPEN_SOURCE || /* since glibc 2.8: */ _POSIX_C_SOURCE >= 200112L fdatasync(): _POSIX_C_SOURCE >= 199309L || _XOPEN_SOURCE >= 500 DESCRIPTION
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) where that file resides. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)). Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed. fdatasync() is similar to fsync(), but does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be correctly handled. For example, changes to st_atime or st_mtime (respectively, time of last access and time of last modi- fication; see stat(2)) do not require flushing because they are not necessary for a subsequent data read to be handled correctly. On the other hand, a change to the file size (st_size, as made by say ftruncate(2)), would require a metadata flush. The aim of fdatasync() is to reduce disk activity for applications that do not require all metadata to be synchronized with the disk. RETURN VALUE
On success, these system calls return zero. On error, -1 is returned, and errno is set appropriately. ERRORS
EBADF fd is not a valid file descriptor open for writing. EIO An error occurred during synchronization. EROFS, EINVAL fd is bound to a special file which does not support synchronization. CONFORMING TO
4.3BSD, POSIX.1-2001. AVAILABILITY
On POSIX systems on which fdatasync() is available, _POSIX_SYNCHRONIZED_IO is defined in <unistd.h> to a value greater than 0. (See also sysconf(3).) NOTES
Applications that access databases or log files often write a tiny data fragment (e.g., one line in a log file) and then call fsync() imme- diately in order to ensure that the written data is physically stored on the harddisk. Unfortunately, fsync() will always initiate two write operations: one for the newly written data and another one in order to update the modification time stored in the inode. If the mod- ification time is not a part of the transaction concept fdatasync() can be used to avoid unnecessary inode disk write operations. If the underlying hard disk has write caching enabled, then the data may not really be on permanent storage when fsync() / fdatasync() return. When an ext2 file system is mounted with the sync option, directory entries are also implicitly synced by fsync(). On kernels before 2.4, fsync() on big files can be inefficient. An alternative might be to use the O_SYNC flag to open(2). In Linux 2.2 and earlier, fdatasync() is equivalent to fsync(), and so has no performance advantage. SEE ALSO
bdflush(2), open(2), sync(2), sync_file_range(2), hdparm(8), mount(8), sync(8), update(8) COLOPHON
This page is part of release 3.27 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2008-11-07 FSYNC(2)

Check Out this Related Man Page

FSYNC(2)						      BSD System Calls Manual							  FSYNC(2)

NAME
fsync -- synchronize a file's in-core state with that on disk SYNOPSIS
#include <unistd.h> int fsync(int fildes); DESCRIPTION
fsync() causes all modified data and attributes of fildes to be moved to a permanent storage device. This normally results in all in-core modified copies of buffers for the associated file to be written to a disk. Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent storage device"), the drive itself may not physi- cally write the data to the platters for quite some time and it may be written in an out-of-order sequence. Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written. The disk drive may also re-order the data so that later writes may be present, while earlier writes are not. This is not a theoretical edge case. This scenario is easily reproduced with real world workloads and drive power failures. For applications that require tighter guarantees about the integrity of their data, Mac OS X provides the F_FULLFSYNC fcntl. The F_FULLFSYNC fcntl asks the drive to flush all buffered data to permanent storage. Applications, such as databases, that require a strict ordering of writes should use F_FULLFSYNC to ensure that their data is written in the order they expect. Please see fcntl(2) for more detail. RETURN VALUES
The fsync() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The fsync() system call will fail if: [EBADF] fildes is not a valid descriptor. [EINTR] Its execution is interrupted by a signal. [EINVAL] fildes refers to a file type (e.g., a socket) that does not support this operation. [EIO] An I/O error occurred while reading from or writing to the file system. If a queued I/O operation fails, fsync() may fail with any of the errors defined for read(2) or write(2). SEE ALSO
fcntl(2), read(2), sync(2), write(2), sync(8), update(8) HISTORY
The fsync() function call appeared in 4.2BSD. 4.2 Berkeley Distribution June 4, 1993 4.2 Berkeley Distribution
Man Page