| |||||||||||||
Better than POSIX?Better than POSIX?Posted Mar 18, 2009 0:45 UTC (Wed) by bojan (subscriber, #14302)In reply to: Better than POSIX? by man_ls Parent article: Better than POSIX?
> They also happen to leave hordes of little empty files after a crash, something which, as has been argued ad nauseam, is a POSIX-compliant way of dealing with a crash.
I know you are joking here, but these files are not empty because of some evil "POSIX compliant" way of dealing with a crash by the FS or kernel. They are empty because they were never committed to the disk by running fsync().
So, it is not that POSIX compliant FS decided to _remove_ that data upon crash. It was never _explicitly_ placed there in the first place, so it cannot possibly be there after the crash.
Sure, you could have a very rare situation where you do run fsync() and you get a zero length file, for all sorts of reasons (usually hardware and kernel driver issues). This is not the case here, however.
> POSIX is just a red herring
I have to disagree here and agree with Ted. The manual page of close is very specific and says:
> A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)
So, if you want have _any_ guarantee that you will see you data on disk _now_, you better fsync().
The manual page of rename(2) is similarly clear on what is being atomic - just the directory entries. Sure, ignore at your peril.
And, finally, the documentation of fsync() is also crystal clear that one is allowed to run it independently on a directory and on a file. Which means that users themselves are allowed to do this separately (and they do). So does the kernel.
Sure, Ted is being gentle to everyone with bugs in their apps, which is fair enough. But, I'll bet $5 they'll hit the same thing on another Unix-like OS in the future, at which point all this screaming will happen again and people writing buggy code will accuse FS writers that it's their fault.
In the meantime, it is easy to take backups of configuration files rarely and restore them if real config files are broken. And it doesn't require running fsync() all the time.
(Log in to post comments)
3 out of 4? Posted Mar 18, 2009 7:22 UTC (Wed) by man_ls (subscriber, #15091) [Link] You seem to think that:
3 out of 4? Posted Mar 18, 2009 8:46 UTC (Wed) by bojan (subscriber, #14302) [Link]
Very funny :-)
Look, it is completely up to you to believe what you want of course. I will do the same. OK?
3 out of 4? Posted Mar 20, 2009 5:02 UTC (Fri) by k8to (subscriber, #15413) [Link]
I'm personally in agreement.
The applications are expecting behavior POSIX does not provide.
It's fine to use a pattern that doesn't request the data be on disk, but you should write the app to deal with the lack of the data being on disk.
This is what I've done many times, in my own software authoring.
Congratulations Posted Mar 20, 2009 11:52 UTC (Fri) by man_ls (subscriber, #15091) [Link] I am sure you also run your Bash console in POSIX mode, never use ls with long options, and only use cp with the four-and-a-half POSIX options. Congratulations. The rest of the world is not so spartan.I hope I don't have to use your software that fsync()s after every file operation. Mistaking durability with atomicity can have dire consequences both for durability and for atomicity. Besides, you are not a lurker and this is not email.
|
|||||||||||||