Re: Safe File Update (atomic)
On Thu, Jan 06, 2011 at 12:57:07AM +0000, Ian Jackson wrote:
> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
> > Then I invite you to implement it, and start discovering all of the
> > corner cases for yourself. :-) As I predicted, you're not going to
> > believe me when I tell you it's too hard.
>
> How about you reimplement all of Unix userland, first, so that it
> doesn't have what you apparently think is a bug!
I think you are forgetting the open source way, which is you scratch
your own itch.
The the main programs I use where I'd care about this (e.g., emacs)
got this right two decades ago; I even remember being around during
the MIT Project Athena days, almost 25 years ago, when we needed to
add error checking to the fsync() call because Transarc's AFS didn't
actually try to send the file you were saving to the file server until
the fsync() or the close() call, and so if you got an over-quota
error, it was reflected back at fsync() time, and not at the write()
system call which was what emacs had been expecting and checking.
(All of which is POSIX compliant, so the bug was clearly with emacs;
it was fixed, and we moved on.)
If there was a program that I used and where I'd care about it, I'd
scratch my own itch and fix it. Olaf seems to really concerned about
this theoretical use case, and if he cares so much, he can either
stick with ext3, which has the property he wants purely by accident,
but which has terrible performance problem under some circumstances as
a result, or he can fix it in the programs that he cares about --- or
he can try to create his own file system (and he can either impress us
if he actually can solve it without disastrous performance problems,
or he can be depressed when no one uses it because it is dog slow).
Note that all of the modern file systems (and all of the historical
ones too, with the exception of ext3) have always had the same
property. If you care about the data, you use fsync(). If you don't,
then you can take advantage of the fact that compiles are really,
really fast. (After all, in the very unlikely case that you crash,
you can always rebuild, and why should you optimize for an unlikely
case? And if you have crappy proprietary drivers that cause you to
crash all the time, then maybe you should rethink using said
proprietary drivers.)
That's the open source way --- you scratch your own itch. I'm
perfectly satisifed with the open source tools that I use. Unless you
think the programmers two decades ago were smarter, and people have
gotten dumber since then (Are we not men? We are Devo!), it really
isn't that hard to follow the rules.
- Ted
Reply to: