Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
Lustre 2.7.0, Lustre 2.4.3, Lustre 2.5.3
-
Lustre 2.4 or newer, file system upgraded from 1.8
-
3
-
15741
Description
LU-2638 reported directory entry corruption related to FID-in-dirent and the “..” entry in HTree directories.
We have since discovered an identical problem in non-HTree directories.
This is essentially exactly the same problem, but it manifests itself slightly different in non-HTree directories. The “..” entry must remain as the second entry in the directory block (FSCK demands this), and when a directory created under 1.8 (now on a 2.4+ server with dirdata enabled) is moved to a new parent, the “..” entry is updated. Exactly as happened in LU-2638, the FID is added to the “..” entry without regards to whether or not there is sufficient space in the second position in the directory block.
In the lucky case where space is already available in the second entry in a directory, the “..” entry is -recreated in the same place, FID attached. If not, it is created in the next available space of sufficient size. This causes complaints from FSCK, and when FSCK repairs this, it places the updated “..” immediately after “.” again, which causes it to overlap the next entry in the directory block. This entry - which is for a real user created file, not . or .. - is moved to Lost + found.
This is because add_dirent_to_buf (used when not in a dx directory) has the same bug as “ldiskfs_update_dotdot”, which was fixed in LU-2638. Because the structure of add_dirent_to_buf is a bit different, the fix looks different as well.
I don’t have time at the moment to commit & update the new ldiskfs patch file to Gerrit, but I will do so shortly. In the meantime, I’m attaching the new patch file & the resulting namei.c to this bug.
The patch is a bit ugly and could probably use improvement, but in my testing, it does fix the bug.
I'll share replication details in a comment.
One ‘technical debt’ problem with this patch:
This patch, and the one for LU-2638, do not simply avoid writing the FID in to the “..” entry. In fact, they avoid writing the entire data section on to the “..” entry, so if there were a pre-existing “..” entry with something else in data other than the FID, that would be lost on directory moves. Currently, it appears that FID-in-dirent is the only user of this extra section.
