Just a thought on the ongoing discussion of dataloss with ext4 vs ext3. Taking the common scenario: Read oldfile create newfile file write newfile data close newfile rename newfile to oldfile When using this scenario, the application writer wants to ensure that either the old or new content are present. With delayed allocation, this can lead to zero length files. Most of the suggestions on how to address this have involved syncing the data either before the rename or making the rename sync the data. What about, instead of 'bringing forward' the allocation and flushing of the data, would it be possible to instead delay the rename until after the blocks for newfile have been allocated and the data buffers flushed? This would keep the performance benefits of delayed allocation etc and also satisfy the applications developers' apparent dislike of using fsync(). It would give better performance that syncing the data at rename time (either using fsync() or automatically) and satisfy the requirements that either the old or new content is present. I am not a filesystem developer, so do not know how feasible this would be. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
