<html><head/><body><html><head></head><body>This entire thread, regardless of implementation, still seems to support the concept that the client needs to retrieve some sort of information from each replica before answering the request.<br>
<br>
That means latency. <br><br><div class="gmail_quote">Whit Blauvelt <whit.gluster@transpect.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">On Tue, Jan 08, 2013 at 02:42:49PM +0100, Stephan von Krawczynski wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">What an dead-end argument. _Nothing_ will save you in case of a split-brain.</blockquote><br />So then, to your mind, there's _nothing_ Gluster can do to heal after a<br />split brain? Some non-trivial portion of the error scenarios discussed in<br />this thread result from a momentary or longer split-brain situation. I'm<br />using "split-brain" in the broad sense of any situation where two sides of a<br />replicated system are out-of-touch for some period and thus get out-of-sync.<br />Isn't that exactly what we're discussing, how to heal from that? Sure, you<br />can have instances of specific files beyond algorithmic treatment. But<br />aren't we discussing how to ensure that the
largest possible portion of the<br />set of files amenable to algorithmic treatment are so-handled?<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">That's the thing about complex systems. Trivial solutions are usually both<br />simple and wrong. Some work most of the time, but there are corner cases. As<br />we see with Gluster even complex solutions tend to have corner cases; but at<br />least in complex solutions the corners can be whittled down.</blockquote><br />Can they? I'd rather say if it is non-trivial it is broken most of the time.<br />Ask btrfs for confirmation.</blockquote><br />Pointing out that a complex system can go wrong doesn't invalidate complex<br />systems as a class. It's well established in ecological science that more<br />complex natural systems are far more
resiliant than simple ones. A rich,<br />complex local ecosystem has a higher rate of stability and survival than a<br />simple, poorer one. That's assuming the systems are evolved and have niches<br />well-fitted with organisms - that the complexity is organic, not just<br />random.<br /><br />Computer software, hardware, and the human culture that supports them also<br />form complex, evolved ecosystems. Can there be simple solutions that help<br />optimize such complex systems? Sure. But to look only for simple solutions<br />is to be like the proverbial drunk looking for his keys under the<br />streetlight, even though he heard them drop a half-block away, because "The<br />light is better here." When people try to apply simple solutions to complex,<br />evolved ecosystems, the "law of unintended consequences" is more the rule<br />than the exception. Solutions that appear simple and obvious should always<br />be suspect. Granted, complex, obscure ones also require scrutiny.
It's just,<br />the simple stuff should never get a pass.<br /><br />Best,<br />Whit<br /><hr /><br />Gluster-users mailing list<br />Gluster-users@gluster.org<br /><a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br /></pre></blockquote></div></body></html></body></html>