First stage of implementing fdatasync(2).

[kib]

Summary

The patch implements fdatasync(2) syscall, which purpose is to request flushing of user data for given file to disk. Difference with fsync(2) is that metadata flush is not required.

The implementation provides non-trivial and believed to be correct VOPs for UFS and msdosfs. For all other filesystems, VOP_FDATASYNC() redirects to VOP_FSYNC(), which should be functionally, but not performance-wise, correct. I believe that ZFS has some code which just needs to be called from VOP to get the implementation as well, but I do not know how.

Still, this is not a complete implementation of the POSIX requirements, because SUSv7 contains the following language:

The fdatasync( ) function shall force all currently queued I/O operations associated with the file
indicated by file descriptor fildes to the synchronized I/O completion state.

I believe that the statement requires OS to complete all queued AIO requests before fdatasync(2) returns. This is not done, the code for the syscall contains placeholder. Still, I think it is useful first step, and right now I am concerned with the correctness of UFS implementation rather then AIO bits.

Test Plan

This was tested by Peter Holm, including specific tests for fdatasync(2).

[avg]

Regarding ZFS, as far as I know, it does not make any distinction between metadata and data operations when it creates ZIL records. And sync commits all ZIL records related to a file to disk. That's how fsync is implemented. So, I do not see any easy way to implement fdatasync that would do a subset of what fsync does.

[kib]

Update after private Kirk' notes:

• invert the flag to kern_fsync().
• change order of the then/else statements in still_dirty calculation in ffs_syncvnode().
• consider fdatasync() done if only indirect metadata blocks are left on dirty buffer queue.

[mckusick]

I am in agreement with the latest proposed change and am ready to have it committed.