Whamcloud - gitweb
LU-6147 lfsck: NOT purge object by OI scrub 93/13493/8
authorFan Yong <fan.yong@intel.com>
Sun, 9 Nov 2014 04:00:41 +0000 (12:00 +0800)
committerOleg Drokin <oleg.drokin@intel.com>
Tue, 3 Feb 2015 17:39:44 +0000 (17:39 +0000)
commitd11360f4cc5d38cd748a97ca05e10121353ae616
tree27d30aa3133b2c95e1786bc7e6ac80deb5efc150
parenta0e2135e3f12c6a19bf211533a4ba070c4783e6d
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>
lustre/include/cl_object.h
lustre/include/lu_object.h
lustre/lfsck/lfsck_lib.c
lustre/obdclass/lu_object.c
lustre/osd-ldiskfs/osd_scrub.c