<br>Hi,<div><br></div><div>I figured that the reason for this issue is that:</div><div><br></div><div>1.<span style="line-height: 1.2;">Precondition:</span><span style="line-height: 1.2;">There are only gateway nodes left in the cluster. So the gateway nodes kept the latest epoch. But as gateway node doesn't count in nr_zones, nr_zones equal to 0.</span></div><div>2.<span style="line-height: 1.2;">The nodes in cluster was restarted, and start to recover from the latest epoch, in which the nr_zones is 0. In function recover_object_from replica, it will skip all the recover process(as nr_copies equals to 0), but return success(as ret was initialled as success).</span></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>static int recover_object_from_replica(<span style="line-height: 1.2;">)</span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>{</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>int nr_copies, ret = SD_RES_SUCCESS, start = 0;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>nr_copies = get_obj_copy_number(oid, old->nr_zones);</div><div><br></div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>for (int i = 0; i < nr_copies; i++) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br></div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>for (int i = 0; i < nr_copies; i++) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br></div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>if (fully_replicated && ret != SD_RES_SUCCESS)</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span> ret = SD_RES_STALE_OBJ;</div><div><br></div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>return ret;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div></div><div>3.<span style="line-height: 1.2;">The node thought it got the latest obj successfully and delete the old version in .stale. but actually there was no obj recovered.</span></div><div><br></div><div>In this case the latest epoch should be the latest one with at least one node who is not in gateway mode. </div><div><br></div><div>Is that possible to let the gateway mode node run without tracking epoch info? In this way the latest epoch will always includes an non-gateway node.</div><div><br></div><div>Thanks,</div><div>Yang</div><div><br></div><div><br></div><div>-----原始邮件-----<br>
<b>发件人:</b> "张扬" <3100100878@zju.edu.cn><br>
<b>发送时间:</b> 2014-11-29 17:44:31 (星期六)<br>
<b>收件人:</b> sheepdog@lists.wpkg.org<br>
<b>抄送:</b> <br>
<b>主题:</b> Fixing method for data wipe bug in the recovery<br><br>Hi,<div><br></div><div>We recently encounter the bug which was reported here:</div><div><a href="https://bugs.launchpad.net/sheepdog-project/+bug/1327037" target="_blank">https://bugs.launchpad.net/sheepdog-project/+bug/1327037</a></div><div><br></div><div>I'm not sure if this is the root cause, but by changing the initial value of ret in function recover_object_from_replica(in recovery.c)</div><div>ret = SD_RES_SUCCESS </div><div>to </div><div>ret = SD_RES_NO_OBJ (actually anything but SD_RES_SUCCESS), i'm able to avoid the lose of data.</div><div><br></div><div>The reason is that, when the node try to recover it self to match the newest epoch, the nr_copies in function <span style="line-height: 1.2;">recover_object_from_replica is zero, so it return ret == SD_RES_SUCCESS while it actually skipped all the recover </span>function<span style="line-height: 1.2;"> in the loop. I don't know why nr_copies is zero though.</span></div><div><span style="line-height: 1.2;"><br></span></div><div><span style="line-height: 1.2;">Thanks,</span></div><div><span style="line-height: 1.2;">Yang</span></div></div>