[LU-11872] Request for option not to follow symlink when setting project ID

• Type: New Feature
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.15.0
• Environment: lustre 2.7.21.3-ddn33
• Assignee: Wang Shilong (Inactive)
• Reporter: Mitsuhiro Nishizawa

Description

Currently, when issuing "lfs project -srp xxxx DIR", command follows symbolic link and set project ID for the target of the link. Customer want a new option not to follow symbolic link.

Can you please think on implementing a new option?

They want to have quota based on directory.
For instance, when there are two users and symlinks are created as follows,

  /home/user01/backup/link01 -> /home/user02/backup/file01
  /home/user02/backup/link02 -> /home/user01/backup/file02

Then, when they issue 'lfs project' command,

  lfs project -p 10001 -s -r /home/user01/backup
  lfs project -p 10002 -s -r /home/user02/backup

Project ID for /home/user01/backup/file02 will be "10002". As they want project IDs for all the files under /home/user01/backup to be "10001", considering this kind of possibility, they need to check all the files under the directory. They just want to simply run a command on a directory.

Issue Links

• is related to: LU-12056 tar doesn't support project id
• is related to: LU-10501 Resource acquired to 'fd' at line 82 may be lost in project_get_xattr()
• is related to: LU-12947 Project quotas: support of symlinks?
• is related to: LU-14062 Setting project ID inheritance on directories can break hardlinking
• is related to: LU-16808 lfs find --printf fails on FIFOs and special files
• is related to: LU-11631 symlink migration should not create remote inodes
• is related to: LU-12480 add STATX_PROJID to upstream kernel

Comments

[Andreas Dilger]

A possibly better solution instead of adding a specific ioctl for this is to use lgetxattr() and lsetxattr() to get/set the trusted.projid virtual xattr from LU-12056 on symlinks. That will also work for other utilities beyond "lfs project" and also works on ldiskfs-mounted MDTs/OSTs directly.

[Wang Shilong (Inactive)]

Patch landed

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/44006/
Subject: LU-11872 quota: add get/set project support for non-dir/file
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: b31792b0e72425c8c7850d69837f08c9f3e95a9c

[Gerrit Updater]

Wang Shilong ([e-mail]) uploaded a new patch: https://review.whamcloud.com/44006
Subject: LU-11872 quota: add get/set project support for non-dir/file
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b34dff90fc6f8d91640f68ee4cf7acfb70bebe17

[Alexander Zarochentsev]

>if it ok to a walkaround ioctl in Lustre before that is better to fix problem completely.. rather than continue https://review.whamcloud.com/#/c/34447 patch.
I think yes.

[Wang Shilong (Inactive)]

It might take some time to have vanilla kernel to support get/change projectID, i pushed a series patch to upstream to change projectID, and we might extend statx() to get project ID of files, but that might take few years to be RH kernel, so i was still wondering if it ok to a walkaround ioctl in Lustre before that is better to fix problem completely.. rather than continue https://review.whamcloud.com/#/c/34447 patch?