Comment 113 for bug 317781

The fundamental problem is that there are two similar but different operations an application developer can request:

1. open(A)-write(A,data)-close(A)-rename(A,B): replace the contents of B with data, atomically. I don't care when or even if you make the change, but whenever you get around to it, make sure either the old or the new version is in place.

2. open(A)-write(A,data)-fsync(A)-close(A)-rename(A,B): replace the contents of B with data, and do it now.

In practice, operation 1 has worked as described on ext2, ext3, and UFS with soft-updates, but fails on XFS and unpatched ext4. Operation 1 is perfectly sane: it's asking for atomicity without durability. KDE's configuration is a perfect candiate. Browser history is another. For a mail server or an interactive editor, of course, you'd want operation 2.

Some people suggest simply replacing operation 1 with operation 2. That's stupid. While operation 2 satisfies all the constraints of operation 1, it incurs a drastic and unnecessary performance penalty. By claiming operation 1 is simply operation 2 spelled incorrectly, you remove an important word from an application programmer's vocabulary. How else is an he supposed to request atomicity without durability?

(And using a "real database" isn't a good enough answer: then you've just punted the same problem to a far heavier system, and for no good reason. As another commenter mentioned, it's a lot easier to administer a set of small, independent text files. There is no reason a filesystem in 2009 should be able to cope a few hundred files.)

The fixes in 2.6.30 seem to make operation 1 work correctly, and that's good enough for me. I don't recommend application developers insert fsync calls everywhere; that will kill performance. Just use operation 1 and complain loudly when filesystems break it. While it may not be guaranteed by POSIX, operation 1's atomicity is nevertheless something any sane filesystme should provide.