Re:Wrong question (Score 1)

Hear, hear. That's exactly the problem. The invariant of rename is useful, and it is useful to be able to get the atomic cutover without ensuring that the file is on disk. The previous ext4 behaviour is utterly useless to everyone. The reason is that there is an important case that hasn't been raised much: where the process doing the renaming isn't the process doing the writing. Consider:

$ echo "Hello, world" > file.new # or some other operation that produces file.new
$ mv file.new file
$ [System crashes some time after mv completes.]

In this case, the shell probably doesn't do an fsync before it closes file.new, so the bug might appear. Basically, the implication of not solving this is the kernel is that every application that writes a file needs to be changed to fsync before closing it, if someone else might later want to rename it over another file. That is equivalent to an enforced fsync_on_close flag, but also requires that every application is changed, and it completely wipes out the lazy allocation, write-behind optimisation that this was all supposed to allow. The only realistic possibility is for mv to open file.new and fsync it before renaming, but that's racy, so the kernel is the only place where this problem can be fixed properly.