Whamcloud - gitweb
LU-3124 llite: To use an extra RPC to transfer layout
authorJinshan Xiong <jinshan.xiong@intel.com>
Thu, 11 Apr 2013 23:11:14 +0000 (16:11 -0700)
committerOleg Drokin <oleg.drokin@intel.com>
Fri, 19 Apr 2013 00:44:56 +0000 (20:44 -0400)
commit9ae3b7e83cd19f4ffdc1e111496ca90971f12061
treec1301201922d2e46a86e5c50e22309eec3cb74bb
parent22b3aa933a155e37bb7ee1e4dde6f3704d30b67f
LU-3124 llite: To use an extra RPC to transfer layout

To support wide stripe, we have to use an extra RPC to transfer
large layout, instead of using LVB buffer in completion AST for
layout lock since it doesn't reserve enough space. Also, to fix
the problem in LU-2807, we decide to transfer layout with an extra
RPC if it has ever been blocked.

In LU-2807, it turns out we can't call mdt_object_find() in ptlrpc
thread context as following may happen:
1. thread1 unlink reaches the MDT;
2. before unlink enqueues lock, thread2 does getattr intent req to
   find and hold object;
3. unlink acquires inodebits dlm lock;
4. thread3 enqueues LAYOUT lock, blocked;
4. thread2 blocked at acquiring dlm lock as well;
5. unlink finishes and releases the lock(the object becomes dying),
   LAYOUT lock's completion_ast will be invoked;
6. mdt_lvbo_fill() calls mdt_object_find() and waits for dying object,
   this will never succeed because thread2 is being blocked at
   completion AST with object held. live locked.

By using extra RPC to fetch layout, we won't have the above problem
any more.

Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Change-Id: If75ae92424ada6ef275e813a87a93acd426eabdc
Reviewed-on: http://review.whamcloud.com/6042
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
lustre/ldlm/ldlm_lockd.c
lustre/llite/file.c
lustre/mdt/mdt_lvb.c