Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
3
-
17441
Description
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 updates request in the OUT RPC during the 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 RPC for repairing during the declare phase as other normal transactions do.
To resolve the trouble, we will make OSP to prepare related update requests (for OUT RPC) after remote transaction started, and trigger the remote updating (RPC sending) 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.