Details
-
Technical task
-
Resolution: Fixed
-
Major
-
None
-
None
-
17772
Description
Currently, when the namespace LFSCK verifies the object's linkEA, it will check the linkEA without ldlm/dt lock firstly, if finds inconsistency, it will acquire the ldlm/dt lock on the object, then re-check the linkEA, if still invalid, it will repair the bad linkEA. For the system containing many inconsistent objects, such double-check mechanism is inefficient.
Be as some improvement, the LFSCK can make some prediction, for example: if former object contains bad linkEA, then when verifies current object, the namespace LFSCK can 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.
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/14008/
Subject:
LU-6350lfsck: lock object based on prediction for bad linkEAProject: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ad40feaee4f58399da8a048fa5342700b8aebc6c