Re: Safe File Update (atomic)
On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o <tytso@mit.edu> wrote:
> 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.
Most of the time one is writing software because it's useful for
oneselves and others. Not because writing software itself is so much
fun. It's about the result.
So focus should be on what those users need/want.
> 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.)
Would you classify the emacs implementation of safe file write
semantics simple or complex?
Why did they not get it right the first time?
IMO it's because the API is hard to use and easy to misuse, while it
should be the other way around.
Hiding behind POSIX semantics is easy but doesn't solve the problem.
> 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.
I think the number of programmers today is much larger than it was two
decades ago and I also think the average experience of the programmer
went down.
Olaf
Reply to: