There is a relatively simple solution here that would allow ext4 to be both
fast and reliable in this case - i.e. never truncate files on crashes after
rename replacements without being forced to commit all data from the
replacement to disk before finishing the rename.
It simply involves putting rename replacement undo records in the
filesystem journal, and on recovery, after rolling the journal forward,
undo-ing any rename replacements for which the data of the replacement
version did not make it to disk. See discussion in comments to Ted's
recent blog entries on the subject for more information.
This could be done with O_TRUNC too, but that would be much more complex,
and contra-Linus I don't see how anyone can rationally expect not to get a
zero length file on recovery if an application explicitly specifies that is
what it wants (before proceeding further).