[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

[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.

[Andreas Dilger]

Di, I'm not sure why you made a new patch, and reserved new ROOT FIDs? AFAIK There is only a singe root FID needed, and there is already MDD_ROOT_INDEX_OID reserved. Coils you please explain?

[Di Wang]

Here is a new patch about root fid. http://review.whamcloud.com/#change,4342

Basically, it reserve 0xffffffffffff0000-0xfffffffffffffffe for root fids, the root fid of each MDT will be [0xffffffffffff0000 + mdt_index, 0, 0], please have a look to avoid duplicate work here.