> You may wish that was what they did, but reality is that "open(filename, O_TRUNC | O_CREAT, 0666)" thing.
Which is exactly what ext4 already works around. In line with reality.
> Harsh, I know. And in the end, even the _good_ applications will decide that it's not worth the performance penalty of doing an fsync(). In git, for example, where we generally try to be very very very careful, 'fsync()' on the object files is turned off by default.
Ah, thinking of doing fsync() after all, are we?
> Why? Because turning it on results in unacceptable behavior on ext3.
And then, the real reality:
> Now, admittedly, the git design means that a lost new DB file isn't deadly, just potentially very very annoying and confusing - you may have to roll back and re-do your operation by hand, and you have to know enough to be able to do it in the first place.
Meaning, make your apps in such a way that an odd crash here and there cannot take out the whole thing.