Comment 76 for bug 317781

@Volodymyr M. Lisivka,

You can opine all you want, but the problem is that POSIX does not specify anything about "hidden transactions", and certainly does not make any guarantees like this. As I said, most modern file systems are doing delayed allocation for speed reasons, so you can expect this to be more of a norm. The patch which is going into 2.6.30 will do this, and by default, when you are replacing files, mostly because I know most application programmers are going to continue to rely on this. However, it's a bad idea to do so.

If you really care about making sure something is on disk, you have to use fsync or fdatasync. If you are about the performance overhead of fsync(), fdatasync() is much less heavyweight, if you can arrange to make sure that the size of the file doesn't change often. You can do that via a binary database, that is grown in chunks, and rarely truncated.

I'll note that I use the GNOME desktop (which means the gnome panel, but I'm not a very major desktop user), and "find .[a-zA-Z]* -mtime 0" doesn't show a large number of files. I'm guessing it's certain badly written applications which are creating the "hundreds of dot files" that people are reporting become zero lengh, and if they are seeing it happen a lot, it must be because the dot files are getting updated very frequently. I don't know what the bad applications are, but the people who complained about large number of state files disappearing should check into which application were involved, and try to figure out how often they are getting modified. As I said, if large number of files are getting frequently modified, it's going to be bad for SSD's as well, there are multiple reasons to fix badly written applications, even if 2.6.30 will have a fix for the most common cases. (Although some server folks may mount with a flag to disable it, since it will cost performance.)