[tahoe-dev] safety and Tahoe Lock Files

[Jim McCoy]

On Mon, Mar 10, 2008 at 2:52 PM, zooko <zooko at zooko.com> wrote:
[...]
>  You are wrong to think that we are unaware of this general
>  principle.  (In fact, I'm slightly surprised that you thought that we
>  were being so naive -- don't you know us better than that?)  What we
>  are discussing here is what trade-offs are possible between
>  consistency, availability/performance, simplicity of implementation,
>  and what abstractions are offered to the user.

I am certain you are aware of it, but your statements that started
this thread seemed to indicate that you had forgotten it.  I have no
doubt that you can handle the multiple readers problem, but multiple
writers are what was being discussed.  This is where you need to be
careful.  The mutable files doc is quite correct in terms of what must
be avoided, but this thread started with you suggesting that lock
files might solve this problem.  Here be dragons...

>  As sometimes happens with rigorous, general theories, it is possible
>  to do better than the celebrated impossibility result suggests, by
>  realizing that your case is not the general case.  For example, the
>  Byzantine Generals result proves that you can't come up with a
>  consensus if more than 1/3 of your nodes are faulty or malicious.

Actually, it is pretty widely known that you can do better than this
depending on the conditions. You can actually get away with far more
than 1/3 of your systems being faulty depending on what your needs are
and what you are willing to tolerate in terms of communication costs.
Read Lamport, lots and lots of Lamport (as the blog post you noted
hints that you should.)  I think you might be able to get away with
"cheap paxos", Lower Bounds for Asynchronous Consensus (the 2004
version), but that depends on what sort of conditions you are willing
to relax in terms of consensus speed; this would work for traditional
backups but less so for a disk that the user expects to appear "live".

jim