https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-13176 Lustre <p>When rename() has a target directory with different project ID from the source directory, the kernel currently returns <tt>-EXDEV</tt>, which forces userspace to perform a full data copy of the file. This is slow when the files are large, and does not provide any security benefit for the user or admin in the end. </p> <p>It would be better to change the project ID to that of the target directory, and assign the quota for the file to the new project ID, the same as is done with <tt>chown()</tt> and <tt>chgrp()</tt> for UID and GID quotas.</p> LU-13176

rename() to another directory should transfer project quota

Improvement Major Resolved Fixed Hongchao Zhang Andreas Dilger easy Tue, 28 Jan 2020 21:48:55 +0000 Fri, 4 Aug 2023 04:28:51 +0000 Mon, 31 Jan 2022 04:39:31 +0000 Lustre 2.15.0 0 11 <p>It looks like the reasoning behind this design choice is described in the email thread "<tt>quota: add project quota support</tt>" between the primary ext4 and XFS developers:</p> <blockquote> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> &gt; ... we should check with the XFS folks what happens if you move a file &gt; from one directory which belongs to one project quota to another &gt; directory that has a different project quota (or no quota whatsoever). </pre> </div></div> <p>Rename to a destination with a different project quota gives EXDEV, same as if you were trying to rename across different filesystems. See <tt>xfs_rename()</tt>.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> &gt; I suspect the right answer is that the quota gets transferred from one &gt; project to another, so that it is a true directory-tree quota system, </pre> </div></div> <p>XFS doesn't transfer the quota from projid to projid because it's borderline impossible to correctly track all the metadata allocation/free operations that can happen in a rename operation and account them to the correct quota. Hence all those corner cases are avoided by treating it as <tt>EXDEV</tt> and forcing userspace to <tt>cp</tt>/<tt>unlink</tt> the files rather than rename.</p></blockquote> <p>I agree that this is much more of a problem for Lustre than it is for local filesystems. As a workaround for this behavior when moving a large directory tree, it seems possible to use "<tt>lfs project</tt>" to change the project ID of the source directory to match that of the target directory before the directory is moved, at which point the "<tt>mv</tt>" operation should just be doing a rename since the project IDs will be the same for the source and target.</p> <p>"Hongchao Zhang &lt;hongchao@whamcloud.com&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/45660" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/45660</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13176" title="rename() to another directory should transfer project quota" class="issue-link" data-issue-key="LU-13176"><del>LU-13176</del></a> mdd: rename file with different project ID<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 2adb3f2bba3e693d1537917abd9038db5dc301f5</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/45660/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/45660/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13176" title="rename() to another directory should transfer project quota" class="issue-link" data-issue-key="LU-13176"><del>LU-13176</del></a> mdd: rename file with different project ID<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 88c26912a3237fb63923bbb7c7b09111f9f30bbe</p> <p>Landed for 2.15</p> Duplicate Related LU-11303 LU-15667 LU-11303 LU-15294 LU-17016 Development Rank 1|i00sqn: Rank (Obsolete) 9223372036854775807