[lustre-discuss] Project quota and odd mv behavior
Hans Henrik Happe
happe at nbi.dk
Wed Dec 17 04:54:10 PST 2025
To be more specific:
Server:
- Lustre 2.15.7
- Rocky Linux 8.10 (4.18.0-553.53.1.el8_10.x86_64)
Client:
- Lustre 2.15.7, but same outcome on 2.15.5
- Rocky Linux 9.6 (5.14.0-570.42.2.el9_6.x86_64)
- glibc-2.34-168.el9_6.23.x86_64
- coreutils-8.32-39.el9.x86_64
On 17/12/2025 13.22, Hans Henrik Happe via lustre-discuss wrote:
> It's 2.15.7.
>
> On 17/12/2025 03.36, Andreas Dilger wrote:
>> There have definitely been some fixes in this area.
>> What version of Lustre are you running?
>>
>>> On Dec 16, 2025, at 07:39, Hans Henrik Happe via lustre-discuss<lustre-discuss at lists.lustre.org> wrote:
>>>
>>> Hi,
>>>
>>>
>>> It seems like the inherited project quota issue [1] with mv has been resolved with XFS in RHEL9. However, Lustre is a bit strange.
>>>
>>> Given a "src" and "dst"(empty) dir these two ways of calling mv behaves differently:
>>>
>>> mv src dst/ (work: no copy)
>>> mv src dst/src (copy, then delete)
>>>
>>> I've attached an strace output for both Lustre and XFS. It seems like mv is handling the fact that Lustre don't have renameat2 a bit differently.
>>>
>>> Before I dig further. Is this behavior known?
>>>
>>> Cheers,
>>> Hans Henrik
>>>
>>> [1]http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/2023-February/018511.html
>>> <lustre-mv.strace><xfs-mv.strace><lustre-mv-copy.strace>_______________________________________________
>>> lustre-discuss mailing list
>>> lustre-discuss at lists.lustre.org
>>> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>>>
Cheers,
Hans Henrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20251217/ea071692/attachment.htm>
More information about the lustre-discuss
mailing list