Whamcloud - gitweb
LU-6350 lfsck: lock object based on prediction for bad linkEA 08/14008/8
authorFan Yong <fan.yong@intel.com>
Wed, 8 Apr 2015 13:32:10 +0000 (21:32 +0800)
committerOleg Drokin <oleg.drokin@intel.com>
Fri, 1 May 2015 03:21:39 +0000 (03:21 +0000)
commitad40feaee4f58399da8a048fa5342700b8aebc6c
treecea2d31d91afcdcdba7dadaf38a13e3523e7620e
parent0a6470219a8602d7a56fe1c5171dba4a42244738
LU-6350 lfsck: lock object based on prediction for bad linkEA

Originally, when the namespace LFSCK verifies the object's linkEA,
it will check the linkEA without related ldlm/dt lock firstly. If
finds bad linkEA (or lost linkEA), it will acquire the ldlm/dt lock
on the object, then re-check the object; if still some inconsistent,
it will repair the inconsistency with the lock.

For the system that contains many inconsistent objects, such double
check mechanism is some inefficient. Be as improvement, the LFSCK can
make some prediction, for example: if the former object contains bad
linkEA, then when verifies current object, the namespace LFSCK will
acquire the ldlm/dt lock on the object in advance; if the prediction
is wrong, it will NOT take ldlm/dt lock in advance for next object.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I16b317305894a07bb372f5ca5e5f22052ff7cd66
Reviewed-on: http://review.whamcloud.com/14008
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
lustre/lfsck/lfsck_internal.h
lustre/lfsck/lfsck_lib.c
lustre/lfsck/lfsck_namespace.c