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? <div>
<br></div><div>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. <br>
<br><div class="gmail_quote">On Mon, Aug 6, 2012 at 4:29 PM, <a href="mailto:erpo41@gmail.com">erpo41@gmail.com</a> <span dir="ltr"><<a href="mailto:erpo41@gmail.com" target="_blank">erpo41@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"><div><div class="h5">On Aug 6, 2012 5:12 PM, "Tony Arcieri" <<a href="mailto:tony.arcieri@gmail.com" target="_blank">tony.arcieri@gmail.com</a>> wrote:<br type="attribution"></div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<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></div></div><div class="im">_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">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></div></blockquote></div>
<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><br></div>