From f06a4efe13faca21ae2a6afcf5718d748bb6ac5d Mon Sep 17 00:00:00 2001 From: Oleg Drokin Date: Fri, 16 Oct 2020 10:25:58 -0400 Subject: [PATCH] LU-14027 ldlm: Do not wait for lock replay sending if import dsconnected If import disconnected while we were preparing to send some lock replays the sending RPC would get stuck on the sending list and would keep the reconnected import state from progressing from REPLAY to REPLAY_LOCKS state waiting for the queued replay RPCs to finish. Set them as no_delay to ensure they don't wait. LU-13600 exacerbated this issue some but it certainly exist before it as well. Change-Id: Id276a0be7657d9ad6cf40ad8e7a165d5cd341cb8 Signed-off-by: Oleg Drokin Reviewed-on: https://review.whamcloud.com/40272 Tested-by: jenkins Reviewed-by: Andreas Dilger Tested-by: Maloo Reviewed-by: Mike Pershin --- lustre/ldlm/ldlm_request.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lustre/ldlm/ldlm_request.c b/lustre/ldlm/ldlm_request.c index 23abc07a..46b3751 100644 --- a/lustre/ldlm/ldlm_request.c +++ b/lustre/ldlm/ldlm_request.c @@ -2482,6 +2482,8 @@ static int replay_one_lock(struct obd_import *imp, struct ldlm_lock *lock) /* We're part of recovery, so don't wait for it. */ req->rq_send_state = LUSTRE_IMP_REPLAY_LOCKS; + /* If the state changed while we were prepared, don't wait */ + req->rq_no_delay = 1; body = req_capsule_client_get(&req->rq_pill, &RMF_DLM_REQ); ldlm_lock2desc(lock, &body->lock_desc); -- 1.8.3.1