Async I/O

That's why you'd have to hang on to your config in buffers until last unique temp file has overwritten the actual file, which is something that programs like gconfd can do easily. At that point, the buffers would get dumped and read of the real config file would be required next time.

Normally, we are talking of about a few seconds to maybe half a minute of such behaviour here (i.e. either the amount of time it takes to finish immediate fsync or the next regular kernel commit). Programs that overwrite the same config file many, many times within half a minute period are really broken, so this should generally not be an issue.

PS. The point of this whole thing with aio_fsync() is to show that there can be many different approaches to address this issue. Sure, it would require a more sophisticated code, but it can be done. If we had inotify with IN_SYNC event, we could use that too in userland to play with backup files and achieve the desired result (and it that case, read of the renamed file would always give the latest config - instead programs would have to rename foo~ into foo if they found one at startup, which would signal a crash).

PPS. As you probably noticed from my previous posts regarding ext4/POSIX, I'd be very interested to have fbarrier(), because I think we need to have a clean, new way of saying this through an API.