mirror of https://github.com/mkerrisk/man-pages
s/sync (3)/sync ()/
This commit is contained in:
parent
748a6c2b4f
commit
8da9ae243a
|
@ -96,7 +96,7 @@ as made by say
|
|||
would require a metadata flush.
|
||||
|
||||
The aim of
|
||||
.BR fdatasync (2)
|
||||
.BR fdatasync ()
|
||||
is to reduce disk activity for applications that do not
|
||||
require all metadata to be synchronized with the disk.
|
||||
.SH "RETURN VALUE"
|
||||
|
@ -134,11 +134,11 @@ to a value greater than 0.
|
|||
.SH 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
|
||||
.BR fsync (2)
|
||||
.BR fsync ()
|
||||
immediately in order to ensure that the written data is physically
|
||||
stored on the harddisk.
|
||||
Unfortunately,
|
||||
.BR fsync (2)
|
||||
.BR 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.
|
||||
|
@ -173,7 +173,7 @@ flag to
|
|||
In Linux 2.2 and earlier,
|
||||
.BR fdatasync ()
|
||||
is equivalent to
|
||||
.BR fsync (2),
|
||||
.BR fsync (),
|
||||
and so has no performance advantage.
|
||||
.SH "SEE ALSO"
|
||||
.BR bdflush (2),
|
||||
|
|
Loading…
Reference in New Issue