Change Details

I would like to be able to initiate the asynchronous equivalent of fdatasync(2) using aio_fsync(O_DSYNC, ...), as allowed by POSIX. Here is a draft patch to do that. However... if we define O_DSYNC, it had better do something non-surprising when passed to open(2)! That is, it should tell write(2) not to flush meta data changes for silly stuff like time stamps on at least UFS, in the hope of going a bit faster. In D19407, kib rejected the idea of defining O_DSYNC as O_SYNC, because that'd be too lazy. So it seems that we first need a separate patch that will do something like: skip the final call to ffs_update() in ffs_write(), if flags & IO_DSYNC and the inode was only modified for non-data integrity reasons. But I am not sure of the details.

I would like to be able to initiate the asynchronous equivalent of fdatasync(2) using aio_fsync(O_DSYNC, ...), as allowed by POSIX. Here is a patch to do that. Builds on D25090 and D25160 which will go in first.

I would like to be able to initiate the asynchronous equivalent of fdatasync(2) using aio_fsync(O_DSYNC, ...), as allowed by POSIX. Here is a draft patch to do that. However... if we define O_DSYNC, it had better do something non-surprising when passed to open(2)! That is, it should tell write(2) not to flush meta data changes for silly stuff like time stamps on at least UFS, in the hope of going a bit faster. In D19407, kib rejected the idea of defining O_DSYNC as O_SYNC, because that'd be too lazy. So it seems that we first need a separate patch that will do something like: skip the final call to ffs_update() in ffs_write(), if flags & IO_DSYNC and the inode was only modified for non-data integrity reasons. But I am not sure of the detailsBuilds on D25090 and D25160 which will go in first.