Messages in this thread | | | Date | Mon, 21 Jun 1999 13:33:21 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] `cp /dev/zero /tmp' (patch against 2.2.9) |
| |
On Mon, 21 Jun 1999, Stephen C. Tweedie wrote:
>> 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/
| |