Whamcloud - gitweb
LU-6147 lfsck: NOT purge object by OI scrub
Originally, when the OI scrub found some inconsistent FID mapping,
it will repair the FID mapping and ask others to reload the object
by purging such object. Such behavior may cause others to hang.
Because if the object corresponding to the FID has already been
established in RAM, and if some other holds the object's reference,
such as the LFSCK engine will hold the .lustre/lost+found/MDTxxxx,
then purging object will set LU_OBJECT_HEARD_BANSHEE on the object,
then the subsequent object find against such FID will be blocked
until the object's reference become zero and re-establish the object
in RAM. Unfortunately, if it is the object's reference holder tries
to find the same object, it will be blocked by itself for ever.
On the other hand, on the server side, the OI scrub will repair
the bad OI mappping, if the object is established in RAM before
its bad FID mapping repaired, then it must be marked as non-exist,
and should not be cached in RAM after the last reference released.
Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I651ef5f5e8f4f478f07bcbb5622b345deed7cb31
Reviewed-on: http://review.whamcloud.com/13493
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>