Whamcloud - gitweb
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>