-----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, [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> 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" <[email protected] > <mailto:[email protected]>> wrote: > > On Mon, Aug 6, 2012 at 4:08 PM, Two Spirit <[email protected] > <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > > _______________________________________________ tahoe-dev mailing > list [email protected] <mailto:[email protected]> > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > > > > _______________________________________________ tahoe-dev mailing > list [email protected] > 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----- _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
