[tahoe-dev] split brain? how handled in tahoe -- docs?

erpo41 at gmail.com erpo41 at gmail.com
Mon Aug 6 23:29:25 UTC 2012


The way I see it, the goal of tahoe is to provide highly reliable
storage--not highly available storage. In my mind, the right solution is to
set H to a number higher than half the number of storage nodes and call the
problem solved.
On Aug 6, 2012 5:12 PM, "Tony Arcieri" <tony.arcieri at gmail.com> wrote:

> On Mon, Aug 6, 2012 at 4:08 PM, Two Spirit <twospirit6905 at gmail.com>wrote:
>
>> If the algorithm is "last writer wins", then any edits by the other
>> disconnected half are lost. Wouldn't it make sense to approach it like a
>> source control merge conflict where both revisions are preserved and
>> presented to the user for the user to resolve? Depending on the length of
>> outage, this could be significant data loss. Even for short outages, if the
>> two halves are unaware of the disconnect, you've got unknown data loss. I
>> think unknown data loss is even worse than known data loss, because you
>> don't even know to go try to retrieve backups. I don't think it is right
>> that data just vanishes without some kind of red flag or ERROR message. Is
>> there any sort of journaling going on to get a list of the exact changes
>> somewhere?
>
>
> For what it's worth, Cassandra employs a last writer wins strategy and
> several people are using it successfully.
>
> An alternative to make it more robust would be to have vector clocks of
> which nodes modified which data. Tahoe could use this information to
> produce "siblings" in the event that the same file is modified by several
> parties. In the event of a conflict, a user could select which sibling they
> wished to use or perform their own conflict resolution. This is the
> approach used by Riak.
>
> --
> Tony Arcieri
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120806/2a26a5ad/attachment.html>


More information about the tahoe-dev mailing list