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

[Two Spirit]

Since when is lost data considered highly RELIABLE storage? It isn't
storage if it doesn't store. in my eyes vanishing data is not acceptable
storage. double penalty to guy who worked hard to finish early, since the
one who wrote last wins. we might as well rename it to "lossy storage" or
"leakage" instead of storage. the issue is not HA because both halves
believe both sides is operational and no data is lost. Is it not true that
a user's expectation is that what they put into the file system, they
should get back from the file system unless there is an error?

you know that feeling you get when you start hearing the hard drive make
clicking noises because you know that there is a chance you might loose
data? not worth it, you don't risk it, dump the drive and get something
that works.  I would at least well document this limitation, so the newbie
who is considering using it knows what he is getting into and if it is a
real concern for their needs or not.

On Mon, Aug 6, 2012 at 4:29 PM, erpo41 at gmail.com <erpo41 at gmail.com> wrote:

> 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
>>
>>
> _______________________________________________
> 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/20120807/c44558b8/attachment.html>