[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

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

[nasf (Inactive)]

In LFSCK 1.5, all FIDs except for IDIF and some special ones which are marked as "I_LUSTRE_NOSCRUB" (for local root, for OI files themselves, and etc), they have FID <=> ino/gen mapping in the OI files. There are two cases for the "ROOT" FIDs (the "/ROOT/.lustre" is similar) exported to client:

1) Upgrading cases.
For the existing old "ROOT" which was created before Lustre-2.4, the IGIF FID will be fixed to the "ROOT" object, and insert the IGIF FID to the "ROOT" LMA, and add "IGIF <=> ion/gen" mapping to the OI file. From now on, this fixed IGIF FID will be reserved for the "ROOT", the client can still use the fixed IGIF FID to access the "ROOT" object after MDT file-level backup/restore.

2) New formatted cases.
For the new "ROOT" which is created since Lustre-2.4, the "

{ FID_SEQ_LOCAL_FILE, MDD_ROOT_INDEX_OID, 0 }

" FID will be fixed to the "ROOT" object, and related FID-in-LMA and FID mapping in OI file are similar as other normal FIDs.

The initial OI scrub can guarantee that the "ROOT" FID to local ino/gen are valid, in spite of whether there will be MDT file-level backup/restore. So the original three issues described in this ticket description are all resolved in LFSCK 1.5.

Tappro, I prefer to use LFSCK 1.5 to resolve the initial three issues you mentioned. As for other improvements in above discussion, please consider rebase your left patch(es) against LFSCK 1.5 patch. How do you think? Thanks!

[Andreas Dilger]

Mike,
will the patch in http://review.whamcloud.com/4682 address the following check:

#if LUSTRE_VERSION_CODE >= OBD_OCD_VERSION(2, 3, 90, 0)
#error "fix this before release"
#endif
                /*
                 * there is one technical debt left in Orion:
                 * proper hanlding of named vs no-name objects.
                 * Llog objects have name always as they are placed in O/d/...
                 */
                if (fid_seq(lu_object_fid(&o->do_lu)) != FID_SEQ_LLOG) {
                        rc = dt_insert(env, root,
                                       (const struct dt_rec *)first_fid,
                                       (const struct dt_key *)dti->dti_buf,
                                       th, BYPASS_CAPA, 1);
                        if (rc)
                                GOTO(out_trans, rc);
                }