https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6631 Lustre <p>ldlm_cli_cancel_req immediately returns if it gets -EWOULDBLOCK(-EAGAIN) from a LDLM_CANCEL request it tried to send, and the client is being evicted before long.</p> <p>Some network errors can be recovered in many cases then we can avoid eviction. (eviction is really annoying in suppress_ping environment. so I want to avoid it as far as I can)</p> <p>that's why I believe ldlm_cli_cancel_req should retry LDLM_CANCEL here.</p> <p>By the way, the patch I'll upload has worked well in Luster-1.8.8 base FEFS for a very long time and the same in Lustre-2.6 based FEFS. I haven't seen any serious issues so far. That's why I'm convinced it will work in Lustre-2.x too.</p> LU-6631

Retry LDLM_CANCEL in ldlm_cli_cancel_req

Bug Major Resolved Not a Bug WC Triage Hiroya Nozaki patch Fri, 22 May 2015 08:20:54 +0000 Tue, 26 May 2015 07:40:06 +0000 Tue, 26 May 2015 07:40:06 +0000 Lustre 2.6.0 Lustre 2.7.0 0 4 <p>Hiroya Nozaki (nozaki.hiroya@jp.fujitsu.com) uploaded a new patch: <a href="http://review.whamcloud.com/14917" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/14917</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6631" title="Retry LDLM_CANCEL in ldlm_cli_cancel_req" class="issue-link" data-issue-key="LU-6631"><del>LU-6631</del></a> ptlrpc: Retry LDLM_CANCEL in ldlm_cli_cancel_req<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 6e0287d739e7217a7e118dc7767e0f7584273573</p> <p>Could you please explain a bit more about where the <tt>&#45;EWOULDBLOCK</tt> error is coming from? I see this in <tt>ptlrpc_import_delay_req()</tt> but only if <tt>req-&gt;rq_no_delay</tt> is set. Is <tt>rq_no_delay</tt> being set in the <tt>LDLM_CANCEL</tt> request somewhere? I don't see it at first glance.</p> <p>I realized that LDLM_CANCEL doesn't have rq_no_resend and rq_no_delay in Lustre-2.x anymore !! so this patch isn't need.</p> Development Rank 1|hzxdvr: Rank (Obsolete) 9223372036854775807 Severity