[LU-838] "lfs path2fid /mnt/lustre" (ROOT) returns inode number

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Affects Version/s: Lustre 2.4.0
• Labels: LB
• Severity: 3
• Assignee: Mikhail Pershin
• Reporter: Andreas Dilger

Description

Running "lfs path2fid" on the Lustre mountpoint (e.g. /mnt/lustre) will return the underlying "ROOT/" directory inode number. This is bad for a number of reasons:

• it exposes the on-disk inode number to userspace as an IGIF value
• this will be broken after a backup/restore cycle
• this value is stored in the "link" xattr of all files in the ROOT/ directory

$ lfs path2fid /mnt/lustre
[0x61ab:0x6cad245e:0x0]

$ getfattr -d -m trusted.link -e hex /mnt/lustre/etc
getfattr: Removing leading '/' from absolute path names

1. file: mnt/lustre/etc
   trusted.link=0xdff1ea11010000002d000000000000000000000000000000001500000000000061ab6cad245e00000000657463

This should probably be fixed by moving MDD_ROOT_INDEX_OID to be 1UL or 2UL, and then returning FID_SEQ_START:MDD_ROOT_INDEX_OID to the client, like:

$ lfs path2fid /mnt/lustre
[0x200000000:0x2:0x0]

All that is needed is to ensure that the ROOT/ inode stores this in the LMA. This has the drawback that FID_SEQ_START is not currently exposed to clients and it fixes MDD_ROOT_INDEX_OID to a specific value (since it will be stored in the "link" xattr).

The alternative is to expose some other SEQ:OID for the root FID.

Issue Links

• is duplicated by: LU-2240 implement index range lookup for osd-zfs.
• is duplicated by: LU-1550 open-by-fid getdents may return inconsistend data
• is related to: LU-2886 create local files using local_storage library
• is related to: LU-2462 debugfs doesn't care about DIRENT_LUFID flag while inserting new entries

Comments

[Jodi Levi (Inactive)]

Closing this ticket per Di's comments.

[Di Wang]

Yes, the rootfid patch should fix this problem. But lfs path2fid /mnt/lustre still return IGIF for upgraded FS, and it only return the new seq root FID for new formatted FS.

I also think we need add some fid2path tests in those upgrade test (conf-sanity 32a/b/c) to verify this in the upgraded FS, and I can add it in another patch(fid2path fixes for DNE). Hmm, we probably should even run the whole sanity/conf-sanity tests on upgraded FS, but this is totally unrelated with this ticket.

[Mikhail Pershin]

I think this bug is fixed by Di patches, Di, is that right? However my patch contains another good fix - create all local files in uniform way using local_storage library and remove old md_local_file lib as well. We can close this bug and open new one, not blocker but major. Or we can edit this one

[Mikhail Pershin]

Andreas, it becomes just "use local_storage library to create local file" bug. I've updated patch already and testing it now.

[Andreas Dilger]

Mike, after the landing of LU-2240, what is left to be done in this bug?

[Andreas Dilger]

Updated patch from DNE series is http://review.whamcloud.com/5257

[Mikhail Pershin]

I will need to update it after lfsck 1.5 in any case, I am fine to rework and land it after DNE too, not big problem.

[Di Wang]

Mike: Do you mind to land this patch after DNE? or you can just assign this ticket to me? I will land this after DNE is landed, otherwise I need rebase my patch again. Thanks!

[Di Wang]

I updated the patch http://review.whamcloud.com/#change,4342 Only 1 root fid, please have a look. Thanks

[Mikhail Pershin]

I have no objections about lfsck to fix this if it does that. Probably this ticket shouldn't be blocker then.

[Di Wang]

Because each MDT should a ROOT dir, though only ROOT on MDT0 will be visible on client side, but I thought in the future, some other tools might need access these ROOT objects, and we might need FIDs for these ROOT dirs? Hmm I might be wrong here, probably these roots might always be special objects, and invisible from outside. I will revert these changes.