Messages in this thread | | | From | Måns Rullgård <> | Subject | Re: Zero length files - an alternative approach? | Date | Sun, 29 Mar 2009 12:22:29 +0100 |
| |
Graham Murray <graham@gmurray.org.uk> 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@mansr.com
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |