<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>you can reproduce this hang-up by following steps:</div>
<div>1) do some intensive CPG_EVENT_DELIVER event operation, such as vdi lookup/add/del</div>
<div>2) then stop some node's corosync sequentially</div>
<br>
<div class="gmail_quote">On Thu, Sep 15, 2011 at 10:30 AM, MORITA Kazutaka <span dir="ltr">
<<a href="mailto:morita.kazutaka@lab.ntt.co.jp">morita.kazutaka@lab.ntt.co.jp</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
At Wed, 14 Sep 2011 11:24:14 +0800,<br>
<div>
<div></div>
<div class="h5"><a href="mailto:zituan@taobao.com">zituan@taobao.com</a> wrote:<br>
><br>
> From: Yibin Shen <<a href="mailto:zituan@taobao.com">zituan@taobao.com</a>><br>
><br>
> This patch prevents a CPG_EVENT_CONCHG event from blocking VM I/Os.<br>
><br>
> for more details, if a CPG_EVENT_CONCHG event occured inside the<br>
> CPG_EVENT_DELIVER and CPG_EVENT_REQUEST event pair(for example:<br>
> a vdi lookup oreration followed by a meta object read operation),<br>
> then whole cluster will hang forever for the meta object operation<br>
> be blocked. this patch delays a CPG_EVENT_CONCHG event handling.<br>
><br>
> Signed-off-by: Yibin Shen <<a href="mailto:zituan@taobao.com">zituan@taobao.com</a>><br>
> ---<br>
> sheep/group.c | 4 +---<br>
> 1 files changed, 1 insertions(+), 3 deletions(-)<br>
><br>
> diff --git a/sheep/group.c b/sheep/group.c<br>
> index eb0c4e2..b9dd9d7 100644<br>
> --- a/sheep/group.c<br>
> +++ b/sheep/group.c<br>
> @@ -1487,10 +1487,8 @@ do_retry:<br>
> list_for_each_entry_safe(cevent, n, &sys->cpg_event_siblings, cpg_event_list) {<br>
> struct request *req = container_of(cevent, struct request, cev);<br>
><br>
> - if (cevent->ctype == CPG_EVENT_DELIVER)<br>
> + if (cevent->ctype == CPG_EVENT_DELIVER || cevent->ctype == CPG_EVENT_CONCHG)<br>
> continue;<br>
> - if (cevent->ctype == CPG_EVENT_CONCHG)<br>
> - break;<br>
<br>
</div>
</div>
The intention of this code is to flush all outstanding I/Os before<br>
processing CPG_EVENT_CONCHG. CPG_EVENT_CONCHG causes a epoch update,<br>
and we want to avoid it while processing I/O requests to ensure a<br>
strong data consistency.<br>
<br>
The pended CPG_EVENT_CONCHG will be resumed after all outstanding I/Os<br>
are finished, so I think this code isn't a problem. If the event<br>
isn't resumed properly, there should be a bug in another area. Are<br>
there steps to reproduce the hang-up?<br>
<br>
Anyway, start_cpg_event_work() should be refactored to be more<br>
readable, I think.<br>
<br>
<br>
Thanks,<br>
<br>
Kazutaka<br>
<font color="#888888">--<br>
sheepdog mailing list<br>
<a href="mailto:sheepdog@lists.wpkg.org">sheepdog@lists.wpkg.org</a><br>
<a href="http://lists.wpkg.org/mailman/listinfo/sheepdog" target="_blank">http://lists.wpkg.org/mailman/listinfo/sheepdog</a><br>
</font></blockquote>
</div>
<br>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.<br>
<br>
本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。<br>
</font>
</body>
</html>