Technical task
Minor Description
When doing a LFSCK -t layout scan to check MDT-OST object connectivity, LFSCK should also verify and correct mismatches of the PRJID, UID, and GID between the MDT inode and OST object(s). The MDT inode values are the only ones visible to userspace applications, but the OST object values are used for quota accounting and should be kept in sync. The UID/GID/PRJID are normally set on the OST objects automatically when they are first modified by the client, but can sometimes get out of sync (e.g. failed/aborted MDT recovery), so LFSCK should repair this inconsistency automatically during scanning.
Attachments
Activity
Marc, the PROJID on the MDT is visible to the users, while the OST is hidden, so by nature the MDT PROJID has to be considered authoritative, and the OST PROJIDs need to be brought in sync, even if it is incorrect. At that point, the MDT PROJID could be corrected, in the unlikely case it is incorrect.
If I understand correctly, the patch or lfsck in general uses the MDT inode PROJID value as the "source of truth" to distribute to the OST objects. However, there seems to be cases where the MDT inode does not have the correct value set and the OST object does. I filled LU-18865 to explain such a case. In this case, lfsck would propagate the wrong PROJID on the OST objects. It seems that the underlying issue is that PROJIDs set on the MDT inode do not consider the client's nodemap while the OST does, resulting in the PROJID mismatch between MDT inode and OST object.
"Hongchao Zhang <hongchao@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58519
Subject: LU-16266 lfsck: fix the PROJID of OST object
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: e263281b3a86f7713c4cf95ecb7afaf6f5fcc9f4
Hi,
There seems no existing test for it, I have tried to test it simply, the UID/GID on OST have been fixed by LFSCK,
but the PRJID is not, will check the LFSCK for it.
Thanks
Hongchao, related to LU-16265, can you please check whether there is an existing LFSCK test case to verify it is correctly (re)setting the UID/GID/PROJID on OST objects during the layout check?
A simple test would be like:
- create a bunch of files+data with non-zero UID/GID/PROJID using "createmany -U 1 -G 1 -P 1 -S 4096"
- sync files to storage, save "lfs quota -a" output, and verify usage is correct (we may already have a quota test like this)
- mount the OSTs as type ldiskfs and reset the IDs for all objects on the ldiskfs mounted OSTs:
oss# chown -R root:root $OSTMNT/O/ oss# lfs project -s 0 -r $OSTMNT/O/
- check that the user/group/project quota is all accounted to root
- run "lctl lfsck_start -A -r -t layout" (and any other options as needed
- confirm that a new "lfs quota -a" matches the previous quota listing saved
If this test is not passing, then some work is needed in LFSCK to repair the quota.
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/58519/
Subject: LU-16266 lfsck: fix the PROJID of OST object
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ee292c13e2101e9ee5190589f6d3c04a75a52c93