>> fdatasync instead is just _fine_ in this regard.
>
>No it isn't. fdatasync has exactly the same requirements here as
>fsync. The only things which fdatasync is allowed to skip are the
>inode timestamps; all other inode and metadata modifications must
>still be synced.
I agree that currently fdatasync is just an alias for fsync. But the
manpage seems a bit different:
DESCRIPTION
fdatasync flushes all data buffers of a file to disk
(before the system call returns). It resembles fsync but
is not required to update the metadata such as access
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
time.
^^^^
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 immediately in order to ensure that
the written data is physically stored on the harddisk.
Unfortunately, fsync will always initiate two write opera
tions: one for the newly written data and another one in
order to update the modification time stored in the inode.
If the modification time is not a part of the transaction
concept fdatasync can be used to avoid unnecessary inode
disk write operations.
The manpage says "the metadata such as" so I thought we could skip all the
metadata (the inode timestamp looked as an example to me). I thought it
would be the application that should know if the last operations changed
the metadata or not. Also I looked Linus's generic_buffer_fdatasync, and I
thought we would only had to call it in the real sys_fdatasync to get
fdatasync working properly on pre-2.3.7.
So if what you said is true (that fdatasync can skip _only_ the
timestamp), then yes, also fdatasync still needs I/O from the buffer
cache.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/