@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. -- 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
