Comment 169 for bug 317781

@Tom

I might not be good at making my point sometimes, but you clearly sum things up very good. Way better than I do.

@Aryeh

In Ext3, too many applications use fsync, I think that was from the ext2 day-and-era, where not syncing could lead to corrupt filesystems, not just empty files. Same with ufs on solaris - what a PITA that that sometimes can be. FAT on usbsticks is even always synced for that reason.

Even gvim does it, firefox too (actually sqlite3). Sometimes I get frustrated by the performance problems when copying a large file, and not being able to surf, that I do kill -9 (firefox hangs forever - fsync is a blocking call). However on the open-temp+fsync+rename, the rename won't happen anymore, as the kill -9 is handled right after the fsync(), hence, no new file. If it would have taken the sheer 1s to complete, nobody is going to kill -9, you'd be too late, the new file is there.

Under ext4, things will improve as Theodore pointed out. However, fsync means real I/O, and harddisks are just painfully slow, where stupid applications fsync-ing too much can and will hurt a machine's performance while not solving the problem of durability. That problem can just best be solved by atomicity with a rename - given the order stays correct.

Atomicity is a simple performance friendly solution to fsync() for me on a journaled filesystem.