[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? 

[Wang Shilong (Inactive)]

I recalled when last time i tried to refresh, i was aware of that patch also has a problem even we could recreate symlinks, because there might still some other type of files could have similar problems eg fifo, so it did not fix problem completely though.

 

I could move forward the patch(sorry for delay), even though i prefer idea new ioctl(parent dir and child name), because that could also fix problem get project ID of symlinks/fifo..

 

Any though?

 

[Alexander Zarochentsev]

> we tried to introduce a new ioctl for Lustre which passed
can https://review.whamcloud.com/#/c/34447 be accepted as a temporary solution till the new kernel interface for changing project id is added to the vanilla kernel and that new kernel gets used by RH?

[Alexander Zarochentsev]

>Alexander, any comment on the resulting inconsistency between project quota inode usage and what "find" would report for the directory, or even that user and group quota will report for the same directory tree?

yes it has a drawback. I want to get a feedback whether it is a serious problem or not. https://review.whamcloud.com/#/c/34447 is not updated for about a year, are there plans to move it forward?

[Wang Shilong (Inactive)]

I don't think it good idea to "do not inherit project id for links", we tried to introduce a new ioctl for Lustre which passed

Parent dir and child name to get/set project ID, this is even better idea than this IMO..