@Theodore: If I understand correctly, ext3's data=ordered mode should make the create/rename method safe even without fsync: after a crash either the old or the new content is visible under the old name. It is unsafe in data=writeback mode, and the O_TRUNC method is always unsafe.
Now the problem is apparently due to ext4 not having ext3's data=ordered behavior, by having delay-allocated data blocks written after journal commit. I believe most ext3 users who choose data=ordered over data=writeback, like me, prefer this mode due to better data integrity in the create/rename case above, not security concerns. Some applications should be fixed to reduce updates and make use of f*sync(), sure, but even given enough time, not all of them can be fixed because some applications are simply too low-level to have any knowledge on the importance of their output and thus the necessity to fsync(). Therefore, in the foreseeable future, many users will probably rely on the integrity guarantees of ext3's data=ordered mode, even though it is not specified by the POSIX spec. If I want performance, I can lengthen the journal commit interval to e.g. one minute, and fsync() is necessary only when losing one minute's changes (NOT the whole file) is unacceptable. Does your patch get ext3's data=ordered behavior back entirely, when this option is used? -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
