<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Any directory renames where it is not just a simple name change (ie. parent directory is
<div>not the same for both source and target) the MDS thread doing the rename will take the</div>
<div>LDLM "big filesystem lock" (BFL), which is a specific FID for global rename serialization. </div>
<div><br>
</div>
<div>This ensures that there is only one thread in the whole filesystem doing a rename that</div>
<div>may create directory loops, and the parent/child relationship is checked under</div>
<div>this lock to ensure there are no loops. </div>
<div><br>
</div>
<div>For regular file renames, and directory renames within a single parent, it is possible</div>
<div>to do parallel renames, and the MDS only locks the parent, source, and target FIDs to</div>
<div>avoid multiple threads modifying the same file or directory at once. </div>
<div><br>
</div>
<div>The client will also take the VFS rename lock before sending the rename RPC, which serializes the changes on the client, but does not help anything for the rest of the filesystem. This unfortunately also serializes regular renames on a single client,
but they</div>
<div>can still be done in parallel on multiple clients. </div>
<div><br>
<div dir="ltr">Cheers, Andreas</div>
<div dir="ltr"><br>
<blockquote type="cite">On Aug 15, 2023, at 20:14, 宋慕晗 via lustre-discuss <lustre-discuss@lists.lustre.org> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial">
<div>Dear lustre maintainers,<br>
There seems to be a bug in lustre *ll_rename* function:</div>
<div><span style="white-space: normal;"><span style="white-space: pre;"></span>/* VFS has locked the inodes before calling this */</span></div>
<div><span style="white-space: normal;"><span style="white-space:pre"></span>ll_set_inode_lock_owner(src);</span></div>
<div><span style="white-space: normal;"><span style="white-space:pre"></span>ll_set_inode_lock_owner(tgt);</span></div>
<div><span style="white-space: normal;"><span style="white-space:pre"></span>if (tgt_dchild->d_inode)</span></div>
<div><span style="white-space: normal;"><span style="white-space:pre"></span>ll_set_inode_lock_owner(tgt_dchild->d_inode);</span></div>
<div><span style="white-space: normal;"><br>
</span></div>
<div><span style="white-space: normal;">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.</span></div>
<div><span style="white-space: normal;">see this in xfs: </span>https://www.spinics.net/lists/linux-xfs/msg68693.html</div>
<div><span style="white-space: normal;"><br>
</span></div>
<div><span style="white-space: normal;">And I am also wondering how lustre deal with concurrent rename ? </span>Specifically, my concern revolves around the
<b>potential for directory loops</b> when two clients initiate renames simultaneously.</div>
<div>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.</div>
<div>Consider the following scenario:</div>
<div><br>
</div>
<div> a</div>
<div> / \</div>
<div> b c</div>
<div> / \</div>
<div> d e</div>
<div> / \</div>
<div>f g</div>
<div><br>
</div>
<div>
<div>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.</div>
<div>Could you please provide clarity on how lustre handles such situations? Your insights would be invaluable.</div>
<div>Thank you in advance for your time and assistance.</div>
<div>Warm regards,</div>
<div>Muhan Song</div>
</div>
</div>
<br>
<span>_______________________________________________</span><br>
<span>lustre-discuss mailing list</span><br>
<span>lustre-discuss@lists.lustre.org</span><br>
<span>http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</span><br>
</div>
</blockquote>
</div>
</body>
</html>