+ * Lustre OST Proxy Device (OSP) is the agent on the local MDT for the OST
+ * or remote MDT.
+ *
+ * OSP object attributes cache
+ * ---------------------------
+ * OSP object is the stub of the remote OST-object or MDT-object. Both the
+ * attribute and the extended attributes are stored on the peer side remotely.
+ * It is inefficient to send RPC to peer to fetch those attributes when every
+ * get_attr()/get_xattr() called. For a large system, the LFSCK synchronous
+ * mode scanning is prohibitively inefficient.
+ *
+ * So the OSP maintains the OSP object attributes cache to cache some
+ * attributes on the local MDT. The cache is organized against the OSP
+ * object as follows:
+ *
+ * struct osp_xattr_entry {
+ * struct list_head oxe_list;
+ * atomic_t oxe_ref;
+ * void *oxe_value;
+ * int oxe_buflen;
+ * int oxe_namelen;
+ * int oxe_vallen;
+ * unsigned int oxe_exist:1,
+ * oxe_ready:1;
+ * char oxe_buf[0];
+ * };
+ *
+ * struct osp_object_attr {
+ * struct lu_attr ooa_attr;
+ * struct list_head ooa_xattr_list;
+ * };
+ *
+ * struct osp_object {
+ * ...
+ * struct osp_object_attr *opo_ooa;
+ * spinlock_t opo_lock;
+ * ...
+ * };
+ *
+ * The basic attributes, such as owner/mode/flags, are stored in the
+ * osp_object_attr::ooa_attr. The extended attributes will be stored
+ * as osp_xattr_entry. Every extended attribute has an independent
+ * osp_xattr_entry, and all the osp_xattr_entry are linked into the
+ * osp_object_attr::ooa_xattr_list. The OSP object attributes cache
+ * is protected by the osp_object::opo_lock.
+ *
+ * Not all OSP objects have an attributes cache because maintaining
+ * the cache requires some resources. Currently, the OSP object
+ * attributes cache will be initialized when the attributes or the
+ * extended attributes are pre-fetched via osp_declare_attr_get()
+ * or osp_declare_xattr_get(). That is usually for LFSCK purpose,
+ * but it also can be shared by others.
+ *
+ *
+ * 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.
+ *