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

Frederik Braun Frederik.Braun+tahoe at ruhr-uni-bochum.de
Tue Aug 7 12:01:28 UTC 2012


Considering your argument about lacking documentation and lost data:

As far as I know, Tahoe defaults to immutable files. This means that
updates (regardless of whether they happen during a split or not) are
new files and the old ones are still recoverable.
Since garbage collection is pretty slow all data would remain available.

Correct me if I'm wrong :)
Frederik


On 08/07/2012 09:16 AM, Two Spirit wrote:
> 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
>>
>>
> 
> 
> 
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
> 



More information about the tahoe-dev mailing list