Yes, this was it. I'd briefly tested project quotas in that directory and the attribute was still set. After I removed the attribute behavior was as expected.

Thanks Andreas and Colin.

Best,
Jesse

On 1/28/20 3:53 PM, Andreas Dilger wrote:
I would also guess project quotas is involved.

That is a behavior that we adopted from upstream ext4 and XFS, but it isn't clear that it is necessary.  It would be better to transfer the quota to the new project in the target directory, which is not different than EXDEV triggering "mv" to copy the file in userspace except that it avoids copying the data for large files.

I've filed https://jira.whamcloud.com/browse/LU-13176 for this issue.

On Jan 28, 2020, at 14:07, Colin Faber <[email protected] <mailto:[email protected]>> wrote:

Can you describe your setup with a little more detail?  Are you running DNE? Are you running project quotas?

On Mon, Jan 27, 2020 at 1:05 PM Jesse Stroik <[email protected] <mailto:[email protected]>> wrote:

    Hello,

    I have an interesting situation one of our lustre file systems
    where I
    cannot rename files or directories across a specific directory
    boundary
    but I can create hard links across the same boundary. The relevant
    section of strace for 'mv' follows:

    =====
    geteuid()                               = 0
    ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
    stat("..", {st_mode=S_IFDIR|0755, st_size=11776, ...}) = 0
    lstat("test.txt", {st_mode=S_IFREG|0644, st_size=765876794, ...}) = 0
    lstat("../test.txt", 0x7fff36c3ff30)    = -1 ENOENT (No such file or
    directory)
    renameat2(AT_FDCWD, "test.txt", AT_FDCWD, "../test.txt", 0) = -1
    EXDEV
    (Invalid cross-device link)
    =====

    The systems I've tested this on are in our nosquash_nids list as they
    were used for cluster array jobs to copy data between a retiring file
    system and a new one. The clients are either 2.10 or 2.12. The file
    system is run by 2.12.2 on zfs.

    nodemap is not active.

    Best,
    Jesse Stroik

    _______________________________________________
    lustre-discuss mailing list
    [email protected]
    <mailto:[email protected]>
    http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

_______________________________________________
lustre-discuss mailing list
[email protected] <mailto:[email protected]>
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Cheers, Andreas
--
Andreas Dilger
Principal Lustre Architect
Whamcloud







Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
lustre-discuss mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Reply via email to