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-1944 Lustre <p>We should extend recovery timer even when we got the replay request instead of until the req is being processed. And also we need add another net_latency in timer extend, one for balance rq_deadline(see ptl_send_rpc), one for resend the req to server.</p> LU-1944

extend recovery timer even during the request queue phase

Bug Minor Resolved Fixed Di Wang Di Wang Fri, 14 Sep 2012 18:28:04 +0000 Mon, 20 Oct 2014 17:54:20 +0000 Thu, 18 Apr 2013 20:39:46 +0000 Lustre 2.4.0 0 1 <p>Could you describe a bit more why this bug occur and how you discover these changes are needed?</p> <p>I found these problem during replay-dual 9 and 10 (resending create/unlink replay req). In these tests MDS will drop the replay req and waiting client to resend the replay request, so the client needs to resend the replay request before the server get timeout and then evict the client. </p> <p>In current master, server calculate the timeout by at_estimate_srv_time + net_latency, and client also calculate the request timeout by at_estimate_srv_time + net_latency, so they are roughly same. i.e. client is actually being evicted on the server side before it resend the replay request, I saw a few failures because of this in replay-dual 9 and 10, in my local test. Here we actually need add another net_latency to server timeout, so once reply drop happens, the resend replay req can arrive server in time. That is why we need 2 * netlatency in the patch.</p> <p>I actually not sure whether we should extend the timeout when we queue the request? what is your idea?</p> <p>Just update the patch to not extending timeout during queue phase. Will add it back when we are clear.</p> <p><a href="http://review.whamcloud.com/3992" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/3992</a></p> <p><a href="http://review.whamcloud.com/4351" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4351</a></p> Development Rank 1|hzvgif: Rank (Obsolete) 6324 Severity