+ *
+ * XXX: NOT prepare out RPC for remote transaction. ((please refer to the
+ * comment of osp_trans_create() for remote transaction)
+ *
+ * According to our current transaction/dt_object_lock framework (to make
+ * the cross-MDTs modification for DNE1 to be workable), the transaction
+ * sponsor will start the transaction firstly, then try to acquire related
+ * dt_object_lock if needed. Under such rules, if we want to prepare the
+ * OUT RPC in the transaction declare phase, then related attr/xattr
+ * should be known without dt_object_lock. But such condition maybe not
+ * true for some remote transaction case. For example:
+ *
+ * For linkEA repairing (by LFSCK) case, before the LFSCK thread obtained
+ * the dt_object_lock on the target MDT-object, it cannot know whether
+ * the MDT-object has linkEA or not, neither invalid or not.
+ *
+ * Since the LFSCK thread cannot hold dt_object_lock before the remote
+ * transaction start (otherwise there will be some potential deadlock),
+ * it cannot prepare related OUT RPC for repairing during the declare
+ * phase as other normal transactions do.
+ *
+ * To resolve the trouble, we will make OSP to prepare related OUT RPC
+ * after remote transaction started, and trigger the remote updating
+ * (send RPC) when trans_stop. Then the up layer users, such as LFSCK,
+ * can follow the general rule to handle trans_start/dt_object_lock
+ * for repairing linkEA inconsistency without distinguishing remote
+ * MDT-object.
+ *
+ * In fact, above solution for remote transaction should be the normal
+ * model without considering DNE1. The trouble brought by DNE1 will be
+ * resolved in DNE2. At that time, this patch can be removed.
+ *
+ *