Re: Safe File Update (atomic)
On Wed, Jan 05, 2011 at 09:38:30PM +0100, Olaf van der Spek wrote:
>
> Performance is important, I agree.
> But you're trading performance for safety here.
... but if the safety is not needed, then you're paying for no good
reason. And if performance is needed, then use fsync().
> > OK, what about simply deferring the commit of the rename until the
> > file writeback has naturally completed? The problem with that is
> > "entangled updates". Suppose there is another file which is written
> > to the same directory block as the one affected by the rename, and
> > *that* file is fsync()'ed? Keeping track of all of the data
> > dependencies is **hard**. See: http://lwn.net/Articles/339337/
>
> Ah. So performance isn't the problem, it's just hard too implement.
> Would've been a lot faster if you said that earlier.
"Too hard to implement" doesn't go far enough. It's also a matter of
near impossibility to add new features later. BSD FFS didn't get
ACL's, extended attributes, and many other features ***years*** after
Linux had them. Complexity is evil; it leads to bugs, makes things
hard to maintain, and it makes it harder to add new features later.
But hey, if you're so smart, you go ahead and implement them yourself.
You can demonstrate how you can do it better than everyone else.
Otherwise you're just wasting everybody's time. Complex ideas are not
valid ones; or at least they certainly aren't good ones.
- Ted
Reply to: