<div class="gmail_quote">On Tue, Aug 7, 2012 at 8:04 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">

in split brain scenario, wouldn't both halves have write capabilities? unless you made some requirement that more than half of the nodes needed to be up in order to write.</blockquote><div><br></div><div>Hi everyone,</div>

<div><br></div><div>This is very much a formalized topic of computer science. If you have a horse in this race I suggest you divest yourself of that horse and spend your time immersing yourself in the literature on the topic.</div>

<div><br></div><div>What the OP refers to as "split brain" is formally known as "partition tolerance", and the properties of partition tolerant systems are formally described by CAP theorem, otherwise known as Brewer's Theorem:</div>

<div><br></div><div><a href="http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf">http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf</a></div><div><br></div><div>If you are not familiar with CAP theorem, I suggest you spend some time reading about it. If you find the above paper too challenging, you might consider reading this one instead: <a href="http://ksat.me/a-plain-english-introduction-to-cap-theorem/">http://ksat.me/a-plain-english-introduction-to-cap-theorem/</a></div>

<div><br></div><div>CAP theorem is a triangle ala Zooko's triangle: we may only consider two of the three vertices at a time. No distributed system can satisfy all three at once. In the context of this debate, we are considering Tahoe to be a partition tolerant system, and I wouldn't suggest otherwise. The question becomes: what does Tahoe do in the face of a network partition?</div>

<div><br></div><div>There are only two options:</div><div><br></div><div>- Available: Tahoe still accepts writes (and all other operations, but writes are the hardest) in the middle of a network partition, like it does today (provided sufficient nodes are available). The current mechanism is "last writer wins" although there are more sophisticated mechanisms available if this property is desirable.</div>

<div>- Consistent: Tahoe sacrifices write availability to ensure strong consistency in the event of a network partition. This can take the form of several algorithms including a singular master with two phase commit or Paxos.</div>

<div><br></div><div>These are the only two options. For those who desire "reliability", these are the only buckets that reliability can be segmented into. So far I have not heard *any* good arguments towards strong consistency. Instead I have heard that Tahoe shouldn't "lose data", but a filesystem loses data if you save over an important file with a junk version. There is nothing specific to Tahoe as a distributed system that can prevent this: even a strongly consistent distributed filesystem can't prevent someone with the appropriate write capability from saving over an important file with garbage.</div>

<div><br></div><div>So please consider that there are only two options here: consistent or highly available. Choose wisely.</div><div><br></div><div>-- </div></div>Tony Arcieri<br><br>