Comment 140 for bug 317781

@Hiten

I agree with your comment, I think. I was about to make that same post.

I would even dare to say that fsync(fd) is an evil call that never should be used by any application. The reason for this is very simple, it doesn't make a difference: if fsync(fd) needs to write 100MB to disk and a power loss occurs, the temp file will always be in state B,C or D. Your application isn't able to even use that file at next startup, as it has no way of telling whether the file is complete or not. fsync(fd) just might improve on things, but the performance hit doesn't justify it's use.

On ext3, fsync(fd) is a gigantic performance hit too when there's one 'big consumer' on the same machine. Even as simple as 2 files copying around can make saving of a file in vim lag behind 30s. Luckily, vim has ':se nofsync' and ':se swapsync='.
Because of this performance problem, I wanted to test ext4, but after reading this bug, it all looks to me that it won't make any difference - I hope I'm wrong on that. Unless ext4 is smarter and fsync(fd) only does that file's data, instead of a 'everything that should go in the transaction log first because it came first'-style algorithm that is in ext3 (which happens to be a lot when you'r copying a file around ~1G).

Again, calling fsync(fd) to make the rename() appear after the close() is IMHO bad coding. It's fixing some one else's problem. Using a tempfile + rename is good application design to fix halfly written files, it would be nice that it stays that way, without waiting 30s for an fsync() when you're copying :-).