<p>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.</p>

<div class="gmail_quote">On Aug 6, 2012 5:12 PM, "Tony Arcieri" <<a href="mailto:tony.arcieri@gmail.com">tony.arcieri@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">On Mon, Aug 6, 2012 at 4:08 PM, Two Spirit <span dir="ltr"><<a href="mailto:twospirit6905@gmail.com" target="_blank">twospirit6905@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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?</blockquote>


<div><br></div><div>For what it's worth, Cassandra employs a last writer wins strategy and several people are using it successfully.</div><div><br></div><div>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.</div>


<div><br></div></div>-- <br>Tony Arcieri<br><br>
<br>_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
<br></blockquote></div>