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

[Zooko Wilcox-O'Hearn]

On Wed, Aug 8, 2012 at 2:36 AM, Tony Arcieri <tony.arcieri at gmail.com> wrote:
>
>> with the Tahoe-LAFS access control
>> architecture -- in which most things are immutable, and most mutable
>> things are writable by few or only one writer -- such cases appear to
>> be very rare.
>
>
> I operate a Friendgrid, and we have a centralized "Incoming" directory into
> which most previously unclassified content is uploaded by many users who
> share the same writecap prior to being moved to a more appropriate location
> by our content curators who have writecaps to, shall we say, the more
> organized directory structure.

Thank you for sharing the use case!

I guess I'm wrong to say that such things are very rare. Unfortunately. ☹

There's a tiny chance that a very unlucky sequence of failures or
network partitions, combined with the uncoordinated use of the same
write cap by multiple people, will result in the irretrievable
destruction of your Incoming directory. (To see why, think how you
need K different shares of that directory to reconstruct it, and each
writer is simultaneously writing out shares of their own new version.
In a very unlucky scenario, each writer would succeed at writing fewer
than K of their own version to the servers, and then suddenly
disconnect from the Net. The result would be that there are fewer than
K shares of each of several different versions, meaning that no
version is recoverable and the directory is lost forever.)

On the other hand, should that unlucky chance not strike, I suspect
that the "automatic merging of directory modifications" feature -- the
one that I just mentioned that I didn't like it and want to remove it
-- is making sure that simultaneous uncoordinated adds and removes of
children from that Incoming directory is reliable.

(I still want to remove it, but now that I see people are relying it,
I now feel an obligation to replace it with something better when
doing so!)

If you want to be safer, you give each uploader their own separate
"Incoming-John" directory, and the curators use a tool to view all of
the separate Incomings. That would eliminate the risk outlined above.
(A tool such as "find" if LAFS is mounted via FUSE, or a custom script
that runs "tahoe ls" on each of Incoming, or a custom web app that
queries the WAPI.)

Regards,

Zooko