Graham Murray <graham@xxxxxxxxxxxxxx> writes: > 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. Consider this scenario: 1. Create/write/close newfile 2. Rename newfile to oldfile 3. Open/read oldfile. This must return the new contents. 4. System crash and reboot before delayed allocation/flush complete 5. Open/read oldfile. Old contents now returned. This rollback isn't obviously, to me at least, without problems of its own. -- Måns Rullgård mans@xxxxxxxxx -- 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
