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

Wim Lewis wiml at hhhh.org
Sat Aug 4 19:34:46 UTC 2012


On 8/3/12 4:16 PM, Two Spirit wrote:
> well, let me back up one then, if two remote offices share a directory,
> and the connectivity between them gets disconnected, each side thinks it
> just lost half its repository, then you site1 adds file1, and site2 adds
> file2 to their respective halfs, not knowing the other site is not
> connected. when they connect back up, what happens? do you at least have
> a file1 and file2 in the same place. I won't even start with the more
> complicated scenarios right now. It sounds like tahoe is more designed
> for a single user from a single location utilizing remote encrypted
> data-stores for that single user. Am I getting closer?

I think that is true. Tahoe doesn't have very good support for two
clients modifying the same mutable file at the same time, even if there
isn't a network partition.

In your example, both files would be stored correctly, because they
would probably be new immutable files. But the two clients' attempts to
update the directory to contain the new files would not be merged
usefully. This is mentioned in the documentation, but you have to know
where to look:


https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/specifications/mutable.rst#the-prime-coordination-directive-don-t-do-that

So the short answer is Tahoe doesn't really handle the situation you
describe (ability to write during a network partition).

I'm just a spectator, not a Tahoe developer, but there has been
discussion on ways to deal with this--- the doc I linked above talks
about creating some kind of lock manager service; on the list, I've seen
discussion of append-only files (a directory could presumably contain an
append-only log of all operations done to it) or simply showing multiple
versions to clients (who could then do conflict resolution on the client
side? I'm not sure). But in general I don't think Tahoe's goal is to
provide true disconnected operation, when less than a quorum of servers
is available.




More information about the tahoe-dev mailing list