Hi Daniel, Am Mittwoch 25 März 2009 schrieb Daniel Phillips: > I will touch briefly on the recent Ext4 issue, where files written by > the write-to-temporary/rename-as-target method would frequently show > up as zero length after a crash instead of having the original or > updated data. > > The problem is, Ext4 holds recently written file data in cache even > across an atomic (journalled) update of directory metadata. While a > strict reading of Posix permits this, application writers do not expect > it and I think we want to define stronger semantics for Tux3. That is, > we should guarantee that a rename will never be committed to disk > before the source file of the rename is flushed.
What about other metadata before data issues: 1) Creating a new file? Ext4 doesn't catch this case. So if you put an hour into configuring your favorite new applications and the system crashes while it is about to write out the configuration file, you probably end of with a 0-byte file again. 2) Overwriting an existing file with truncate()? I think case 1 would be nice to have covered as well, I don't care much if case 2 will fail, cause I think application programmers should avoid that strategy, as the rename approach seems way saner to me. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
