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

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't think there would be any lost data if you followed erpo41's
suggestion and set H higher than half the number of storage nodes. In
the event of a partition there would be at most one component with H
or more nodes, where writes would succeed; all other components would
have fewer than H nodes, so writes would block. Thus no data would be
lost, but the service would be unavailable to some or all users.

Cheers,
Michael

On 07/08/12 08:16, 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 
> <mailto:erpo41 at gmail.com> <erpo41 at gmail.com
> <mailto: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 
> <mailto:tony.arcieri at gmail.com>> wrote:
> 
> On Mon, Aug 6, 2012 at 4:08 PM, Two Spirit <twospirit6905 at gmail.com
> <mailto: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 <mailto: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 <mailto: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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQINGzAAoJEBEET9GfxSfM5ywH/2cgyQk0oT5wJBptYTuCX5Hw
zsCbRqzzDACo+DLHrAkc52Bmt/hCpxLJZV7fPbbleURyjX532rU1x5ooU3uJLZo0
toGaIB9zpyDT0EOZDLOB8p5CrtV6Sz6FzqKxnW7iVsnjZaiZei6d0pwtRA+MvVFx
2/ZCp2yybufrH2CAadzqWx9RMfCk34mQUPMnQ1YhcePEhartBqIeQJQpKcRz5Gm6
+StOVa5K5LUie6kb8AOTtF9pnRQ0tLkwFWoMC3I+xg2t1pbwPE4oTj+oOAQZ5n7g
diOL7sxBsu2hvPEJDmOt9nhH8aSa/BdzGRqb9nOnHLdD5iZygKHGubA5FiRt6y4=
=Wenc
-----END PGP SIGNATURE-----