Details
-
Technical task
-
Resolution: Won't Fix
-
Major
-
None
-
None
-
None
-
8897
Description
The more complicate case is rename between different striped directories, and there might be four MDTs involve in this process. (mv dir_S/src dir_T/tgt, MDT1 holds the source stripe of dir_S where the name entry of src is located, MDT2 holds src object, MDT3 holds the target stripe of dir_T where the name entry of tgt is located, MDT4 holds tgt object)
1. The client sends rename request to MDT4 if the tgt object exists, otherwise to MDT2 where the src object exists (though this is not a hard requirement). This is the master MDT.
2. If the clients sends the RPC to an MDT and it looks up the tgt name under DLM lock and tgt object exists on a remote MDT, the MDT will return -EREMOTE and the client must resend the RPC to the MDT with the tgt object.
3. If the renamed object is a directory, the master MDT acquires the global rename lock. The master MDT gets the LDLM lock of dir_S and dir_T stripe according to their FID order, then gets the LDLM lock of their child name hashes.
4. If the renamed object is a directory the master MDT checks the relationship between the dir_S and dir_T stripes. If the dir_S is the parent of tgt, the rename is not allowed
5. MDT1 deletes entry src and set ctime/mtime of dir_S.
6. If the renamed object is a directory MDT2 deletes old dir_S ".." entry and insert new dir_T ".." entry, sets ctime/mtime of src and also updates the linkEA of src.
7. The master MDT deletes old entry tgt if it exists, and insert new entry tgt with the src object FID, and also updates the link count of local stripe if this is a directory.
8. If the renamed object is a directory then the master MDT releases global rename lock
9. If tgt object exist, MDT4 destroys tgt.
10. If the object being renamed is itself a striped directory, only the master stripe will have its ".." and linkEA entry updated.