[LU-16265] automatically set projid on objects with projid=0

• Type: Technical task
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.17.0
• Labels: easy quota
• Assignee: Hongchao Zhang
• Reporter: Andreas Dilger

Description

Occasionally it is possible that the projid of an OST object does not get the projid set from the MDS, even though the projid is set correctly on the MDT inode and appears as correct when accessed by "lfs project <file>" since the projid is only fetched from the MDT inode. This may lead to incorrect project quota space accounting for that file (the inode accounting is correct since this only counts MDT inodes).

It would seem relatively straight forward to have OST object-modifying RPCs with obdo.o_projid != 0 to update OST objects that have projid==0. This would be the same one-shot mechanism to set the projid for OST objects as is done with UID/GID on first write. This depends on the clients consistently setting obdo.o_projid with the bulk write and setattr RPCs, and the OST to check this, but it can be done without interoperability concerns, especially since the o_projid would always relate to the inode and has no relation to the process that is accessing the file.

While I don't think many existing objects are written after they are first created, I believe we already do atime updates for files once a day, so the projid=0 fix could be combined with that check to avoid adding extra overhead on file access.

It also seems prudent to have a mechanism to automatically repair OST objects that are missing the PROJID when accessed by "read-only" RPCs like OST_READ, OST_GETATTR, LDLM_GLIMPSE by scheduling this update to a background workqueue. This shouldn't be done during the processing of the read-only RPC, since it can lead to these threads being blocked by journal transaction handling, and cause problems for other clients accessing the filesystem. Instead, this should be done by a low-priority background thread/workqueue. The task can confirm that the object access mode is still 07666 before updating the inode IDs, to avoid race conditions with incoming OST_SETATTR RPCs that might have changed them in the meantime.

Issue Links

• is related to: LU-16988 mirror extend by FID does not set projid
• is related to: LU-18756 tag all OST objects with parent FID
• is related to: LU-18757 'truncate' does not save IDs on objects

Comments

[Peter Jones]

Merged for 2.17

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/58301/
Subject: LU-16265 ofd: update projid on OST by Client
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 47ce8c5341bccdc5f8ce044be5268569d217ed5d

[Gerrit Updater]

"Hongchao Zhang <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58301
Subject: LU-16265 ofd: update projid on OST by Client
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1efcc14ed647074f8dc1f1a35fdc8d3e0062f33a