[LU-3314] failed to check ".lustre" for the MDT upgraded from Lustre-2.x (x <= 3)

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.4.0
• Affects Version/s: Lustre 2.4.0
• Labels: LB fid
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: nasf (Inactive)

Description

For lustre-2.x (x <= 3), the ".lustre" object has NO FID-in-LMA, so the client will get IGIF for the ".lustre" object when the MDT restart. From the OI scrub view, when the MDT upgrade to Lustre-2.4, it does not know whether there are some alive clients have cached ".lustre" IGIF during the upgrading, so it has to generate IGIF-in-LMA and IGIF-in-OI for ".lustre" object. It will cause the others on the MDT failed to check "fid_is_dot_lustre()".

static inline int fid_is_dot_lustre(const struct lu_fid *fid)
{
        return unlikely(fid_seq(fid) == FID_SEQ_DOT_LUSTRE &&
                        fid_oid(fid) == FID_OID_DOT_LUSTRE);
}

Comments

[Peter Jones]

Landed for 2.4

[nasf (Inactive)]

The current solution is that:

Use fixed FID {FID_SEQ_DOT_LUSTRE, FID_OID_DOT_LUSTRE, 0} for ".lustre" in spite of whether there are some old clients cached the ".lustre" IGIF or not. It enables the check "fid_is_dot_lustre()" on the MDT, although it will cause that the old connected clients cannot access the ".lustre" with the cached IGIF.

Usually, it is rare case for the old connected clients to access the ".lustre" with cached IGIF.

[Ned Bass (Inactive)]

Andreas, thanks a lot for the heads up.

[Andreas Dilger]

Chris, Ned,
This is advance warning that the above patch will potentially cause clients that are using the .lustre/ to be unable to access this directory until the next time they are remounted. We do not expect this to affect (m)any users, since .lustre is only used by lustre_rsync and HSM and "lfs fid2path", but it is worthwhile to alert you anyway.

[nasf (Inactive)]

This is the patch:

http://review.whamcloud.com/#change,6309