Messages in this thread |  | | | Date | Sun, 29 Mar 2009 19:49:08 +0300 | | From | Avi Kivity <> | | Subject | Re: Zero length files - an alternative approach? |
| |
Graham Murray wrote: > 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. >
This has been suggested, I believe. In filesystem terms, it means inserting a barrier before the rename operation, meaning that any write operations needed to carry out the rename must not take place until all write operations from the previous calls have completed.
-- error compiling committee.c: too many arguments to function
|  |