[LU-4514] lfsck on 2.x only file system updates igif file count

• Status: Open
• Project: Lustre
• Affects Version/s: Lustre 2.4.1
• Type: Bug
• Priority: Trivial
• Reporter: Rajeshwaran Ganesan
• Assignee: Lai Siyao
• Resolution: Unresolved
• Severity: 3

Description

KIT has a question about lfsck and igif files. We ran into LU-2842 due to a 1.8.x filesystem upgraded to 2.1.x and then 2.4.x. We successfully resolved that issue, but running lfsck on other filesystems led to unexpected results:

I just started "es_lfsck --start"
anyway on a currently not much used file system and was a bit
astonished about the following part of the "es_lfsck --status" output:
checked: 62745
updated: 371
failed: 0
prior_updated: 0
noscrub: 2783
igif: 382
Since the file system has not been created or mounted with Lustre 1.8
I thought that nothing should be updated. Can you explain these numbers?

Basically we are unsure about where the updates and igif files are coming from since this filesystem has always been 2.x, and we were under the impression that igif files were only on 1.8->2.x filesystems.

Comments

[Peter Jones]

Lai

Could you please advise on this one?

thanks

Peter

[Andreas Dilger]

I think there are a few internal Lustre files that get IGIF FIDs assigned when LFSCK is run. Not totally sure which ones those are for sure, but since LFSCK was only added in 2.4.0, and some of the internal files were added/changed in older releases they may not have had LMA xattrs (which hold the FID).

In summary, I don't think there is a problem, but hopefully Fan Yong can confirm.

[Kit Westneat (Inactive)]

Yeah, everything seems to be running fine. I thought it could just be Lustre internal files (I saw LU-4392), but 300+ files seems like a lot.

[nasf (Inactive)]

Right Andreas, for old Lustre-2.x, there were some local objects without FID-in-LMA. From the LFSCK/OI_scrub view, if we do not know their local names/FIDs, they will be in-distinguishable from IGIF objects, so OI_scrub will assign IGIF mode FIDs to them. It is harmless. As for the count, we can list the local files under "/" via debugfs. I suspect there are some log files.