A while ago, there has been some discussion about ext4 potentially leaving empty files after an unclean unmount, summed up pretty well in this article. Basically, because of delayed allocation, writes can be kept in the write cache for a much longer time than the default commit interval of the ext journal (5 seconds).
The problems seem to have been fixed in a patch that forces block allocation in certain situations, thereby forcing the data to disk after at most 5 seconds by default.
I'm wondering what happens when an application overwrites existing parts of a file, without truncating or appending the file itself. Will that be forced to disk within 5 seconds as well?
It seems like a different situation than appending to a file: when appending, the file size changes, which is a metadata change; therefore, a journal commit will be necessary within 5 seconds, and because of data=ordered, the data will have to be written before that because of security concerns (otherwise parts of deleted files of other users could show up for the owner of the appended file).
When just overwriting file data, there is no reason why the data write should have to happen before the metadata journal commit, as the old data belongs to the same user as the new one. So does the write happen before the commit anyway, or can it be delayed longer than the journal commit interval? If so, how long?
Update: I know that all this is irrelevant when doing the right thing, that is, using fsync(). (This was the main reason for all the discussion about ext4 and data loss - the problem only concerned applications not fsync()ing, or not at the right moments.) I'm not writing my own application, I'm asking because I don't know whether all of my applications do the right thing, and I want to know an approximate timeframe for such "dangerous" writes. The reason for asking is that my graphics driver causes kernel panics regularly, and I want to know whether I have to worry about more than the last 5 seconds of data writes.