Whamcloud - gitweb
LU-8306 ldlm: send blocking ASTs after lock replay 16/24716/13
authorNiu Yawei <yawei.niu@intel.com>
Wed, 25 Jan 2017 14:52:34 +0000 (22:52 +0800)
committerOleg Drokin <oleg.drokin@intel.com>
Tue, 14 Mar 2017 02:58:43 +0000 (02:58 +0000)
commit2ae4276ed35c0d89bde8029982e089b916620ae3
treef1e880ab9e3dfb9e30a93826a54936d3142e8a3f
parent8b7a8056ef50c1a27e9ade1f0523beef3a5fe393
LU-8306 ldlm: send blocking ASTs after lock replay

If blocking AST wasn't received by client before recovery,
we need to scan the whole waiting lock list to send blocking
ASTs after lock replay done, otherwise, client could be
evicted unpurposely like following:

- cl1 has a granted lock;
- cl2 has a waiting lock, BL AST is sent but lost on a way;
- failover, locks are replayed and applied on the server in
  the correct order;
- waiting lock is just put to the resource, no new BL AST
  is re-sent, no timeout can happen for the granted lock on
  server, no timeout for the waiting lock on client;
- cl2 will be hanging for a long time until cl1 will cancel
  its aged lock; may lead to cl2 eviction.

Signed-off-by: Niu Yawei <yawei.niu@intel.com>
Change-Id: I2a3fecf3b7fa79f96874d5ae21c599725334d9a5
Reviewed-on: https://review.whamcloud.com/24716
Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com>
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
lustre/include/lustre_dlm.h
lustre/ldlm/ldlm_extent.c
lustre/ldlm/ldlm_flock.c
lustre/ldlm/ldlm_inodebits.c
lustre/ldlm/ldlm_internal.h
lustre/ldlm/ldlm_lib.c
lustre/ldlm/ldlm_lock.c
lustre/ldlm/ldlm_plain.c
lustre/ofd/ofd_dlm.c