<br><br>
<div class="gmail_quote">On Thu, May 3, 2012 at 3:37 AM, MORITA Kazutaka <span dir="ltr"><<a href="mailto:morita.kazutaka@gmail.com" target="_blank">morita.kazutaka@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">At Wed,  2 May 2012 15:12:49 +0800,<br>
<div class="im"><a href="mailto:yaohaiting.wujue@gmail.com">yaohaiting.wujue@gmail.com</a> wrote:<br>><br>> From: HaiTing Yao <<a href="mailto:wujue.yht@taobao.com">wujue.yht@taobao.com</a>><br>><br>> Sometimes we need node can be back in a while.<br>
><br>> When we need this:<br>><br>> 1, restart sheepdog daemon for ugrade or other purpose<br>><br>> 2, the corosync driver lose its token for a short while<br><br></div>This is a corosync specific problem, and should be handled by changing<br>
parameters in corosync.conf, I think.<br></blockquote>
<div> </div>
<div>For cluster storage, storage system should deal with temporary node or network failures. It can not assume the cluster is always stable. Changing parameter of corosync can not eliminate the temporay node failue because of some protocol reasons. I am not sure zookeeper and other drivers have same problems, but zookeeper also has the timeout that zookeeper server can not commnunicate with the node. I think it alos can not avoid the problem on some conditions.</div>

<div> </div>
<div>I tried to implement the similar solution with Amzon Dynamo for temporary node or network failures. Perhaps I  should keep the hinted handoff of failed node on the VM hosted node, so I reused the object cache to keep the hinted handoff. With the cache, the I/O will not be blocked. </div>

<div>  </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>So I think the main benefit of this patchset is to allow us to restart<br>sheep daemons without changing node membership, but what's the reason<br>
you want to avoid temporal membership changes?  Sheepdog blocks write<br>I/Os when it cannot create full replicas, so basically we should<br>remove the failed nodes from node membership ASAP.<br></blockquote>
<div> </div>
<div>Restarting the daemon will lead to two times of data recovery. If we upgrade the cluster with much data, the lazy repair is useful. </div>
<div> </div>
<div>When we format the cluster, we can specify the temorary failure detection on/off. When it is on, there is an optional lazy reparr for eager repair.</div>
<div> </div>
<div>Thanks</div>
<div>Haiti </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>Thanks,<br><br>Kazutaka<br>
<div class="HOEnZb">
<div class="h5"><br> </div></div></blockquote></div>