Dear lustre maintainers, There seems to be a bug in lustre *ll_rename* function: /* VFS has locked the inodes before calling this */ ll_set_inode_lock_owner(src); ll_set_inode_lock_owner(tgt); if (tgt_dchild->d_inode) ll_set_inode_lock_owner(tgt_dchild->d_inode);
Here we lock the src directory, target directory, and lock the target child if exists. But we don't lock the src child, but it's possible to change the ".." pointer of src child. see this in xfs: https://www.spinics.net/lists/linux-xfs/msg68693.html And I am also wondering how lustre deal with concurrent rename ? Specifically, my concern revolves around the potential for directory loops when two clients initiate renames simultaneously. In the VFS, there's a filesystem-specific vfs_rename_mutex that serializes the rename operation. In Ceph, I noticed the presence of a global client lock. However, I'm uncertain if the MDS serializes rename requests. Consider the following scenario: a / \ b c / \ d e / \ f g If Client 1 attempts to rename "c" to "f" while Client 2 tries to rename "b" to "g" concurrently, and both succeed, we could end up with a loop in the directory structure. Could you please provide clarity on how lustre handles such situations? Your insights would be invaluable. Thank you in advance for your time and assistance. Warm regards, Muhan Song
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
