Whamcloud - gitweb
LU-6138 lfsck: NOT hold reference on pre-loaded object 66/13666/5
authorFan Yong <fan.yong@intel.com>
Thu, 20 Nov 2014 04:55:33 +0000 (12:55 +0800)
committerOleg Drokin <oleg.drokin@intel.com>
Wed, 18 Feb 2015 22:08:50 +0000 (22:08 +0000)
commit755c04eba3f52245ecddd5c0d7a205988181d7d1
treeb205338b4c818ed3025e876c2320c06a7224da6c
parentd0f1eb789697ab49b02d3be14b35d7d40c895d14
LU-6138 lfsck: NOT hold reference on pre-loaded object

To improve the LFSCK performance, the LFSCK main engine will pre-load
the object locally or remotely, then generate related LFSCK request
that reference the pre-loaded object, and then push the request into
related LFSCK pipeline. The LFSCK assistant thread will handle the
LFSCK request some later asynchronously.

Originally, the LFSCK request holds the pre-loaded object reference,
so the assistant thread can handle it directly without locating the
object by FID again. But holding the object reference will cause the
object cannot be purged out RAM. If some LFSCK request has held the
object, and some other unlinked the object before the LFSCK assistant
thread handling the LFSCK request, then the unlinked object will be
cached in RAM until the last reference released. Because the LFSCK
main engine and assistant thread run asynchronously, we do not know
when the LFSCK request that holding the object reference will be
handled. If the assistant thread needs to locate the object with
the same FID before that, it will fall into self-deadlock for ever.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I516653aa2143bb32a5f350b314951b78dead3e79
Reviewed-on: http://review.whamcloud.com/13666
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@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_layout.c
lustre/lfsck/lfsck_namespace.c
lustre/lfsck/lfsck_striped_dir.c