> The other thing which you seem to be assuming is that applications > which care about precious data won't use fsync(2). And in general, > it's been fairly well known for decades that if you care about your > data, you have to use fsync(2) or O_DIRECT writes; and you *must* > check the error return of both the fsync(2) and the close(2) system > calls. Emacs got that right in the mid-1980's --- over 30 years ago. > We mocked GNOME and KDE's toy notepad applications for getting this > wrong a decade ago, and they've since fixed it. That's also because our fsync no longer sucks rocks. It used to be possible for a box under heavy disk I/O to take minutes to fsync a file because our disk scheduling was so awful (hours if doing a backup to USB stick). The problem I think actually is a bit different. There isn't an int fbarrier(int fd, ...); call with more relaxed semantics so that you can say 'what I have done so far must not be consumed by a reader until we are sure it is stable, but I don't actually need it to hit disk right now'. That's just a flag on buffers saying 'if we try to read this, make sure we write it out first', and the flag is cleared as the buffer hits media in writeback. All of this is still probabilities. I can do all the fsync's I like, consume the stable data, cause actions over the network like sending people goods, and then the server is destroyed by a power surge. Transactions are a higher level concept and the kernel can't fix that. Alan
