[LU-4392] LFSCK shouldn't assign FIDs, linkEA to files in "/" directory

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.1
• Type: Bug
• Priority: Major
• Reporter: Andreas Dilger
• Assignee: Andreas Dilger
• Resolution: Low Priority
• Severity: 3

Description

It appears that some files in the MDT root directory (e.g. backups of fld, seq_srv, seq_cli, etc) are readable via $MOUNT/.lustre/fid/ and have an IGIF FID assigned to them. These files were created in the root directory of my test filesystem when mounted as ldiskfs some time ago for backup purposes.

The shell also thinks that these FIDs have write permission (i.e. test -w "$MOUNT/.lustre/fid/[0x2686:0xc40fa169:0x0]" returns 0), even though I get a permission denied error trying to modify them, so normal write permission checks will fail.

That seems to be a problem with LFSCK adding these files into the OI when they shouldn't be. The originals of these files correctly have SEQ 0x200000001 and get an error from obf_lookup(), but I think it makes sense to default to make all files in the top-level MDT/OST root directory inaccessible via FID (NO_OI flag?) during the initial LFSCK namespace scan, and only add files under ROOT/ to the OI.

Comments

[nasf (Inactive)]

According to current initial OI scrub implementation, it should assign local FIDs to those local files, instead of IGIF:

static const struct osd_lf_map osd_lf_maps[] = {
…

        /* fld */
        { "fld", { FID_SEQ_LOCAL_FILE, FLD_INDEX_OID, 0 }, OLF_SHOW_NAME,
                NULL, NULL },
…

        /* seq_ctl */
        { "seq_ctl", { FID_SEQ_LOCAL_FILE, FID_SEQ_CTL_OID, 0 },
                OLF_SHOW_NAME, NULL, NULL },

        /* seq_srv */
        { "seq_srv", { FID_SEQ_LOCAL_FILE, FID_SEQ_SRV_OID, 0 },
                OLF_SHOW_NAME, NULL, NULL },
…

};

So I wonder that how you get the IGIF for those local files?

[Andreas Dilger]

This was on Lustre 2.4.1. I deleted the "link" xattr from "seq_srv", "seq_ctl", "REM_OBJ_DIR", "oi.16", "fld", and "capa_keys" files. I'm now starting a new LFSCK run on the MDT, so it will hopefully tell us if this was caused by LFSCK or not. It might have also been caused by the MDT code itself when it was creating these files for the first time at mount?

[nasf (Inactive)]

Strange, I do not think the MDT code itself will cause "link" xattr to be created for those local special objects. So if the "link" xattr is created on those objects, it should be done by LFSCK by wrong. Unfortunately, I cannot reproduce the issues in my local test.

What's result for your further verification?

[Andreas Dilger]

This hasn't shown to be a problem for any normal usage. Close for now.