[LU-6578] inodebit locks for remote entries.

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.7.0, Lustre 2.5.3, Lustre 2.8.0
• Fix Version/s: Lustre 2.8.0
• Type: Bug
• Priority: Blocker
• Reporter: Di Wang
• Assignee: Lai Siyao
• Resolution: Fixed
• Labels: dne2
• Severity: 3

Description

int mdc_intent_getattr_async(struct obd_export *exp,
                             struct md_enqueue_info *minfo,
                             struct ldlm_enqueue_info *einfo)
{
        struct md_op_data       *op_data = &minfo->mi_data;
        struct lookup_intent    *it = &minfo->mi_it;
        struct ptlrpc_request   *req;
        struct mdc_getattr_args *ga;
        struct obd_device       *obddev = class_exp2obd(exp);
        struct ldlm_res_id       res_id;
        /*XXX: Both MDS_INODELOCK_LOOKUP and MDS_INODELOCK_UPDATE are needed
         *     for statahead currently. Consider CMD in future, such two bits
         *     maybe managed by different MDS, should be adjusted then. */
        ldlm_policy_data_t       policy = {
                                        .l_inodebits = { MDS_INODELOCK_LOOKUP |
                                                         MDS_INODELOCK_UPDATE }
                                 };
        int                      rc = 0;
        __u64                    flags = LDLM_FL_HAS_INTENT;
        ENTRY;

Issue Links

• is related to: LU-6829 runtests test_1: MDS hung

Comments

[Andreas Dilger]

Di, what is needed to fix this? Can you please add a description, and maybe Lai can work on it?

[Di Wang]

lmv_intent_getattr_async needs to be fixed to handle such cross-MDT object. So

1. If the parent and child are in the same MDT. then lmv_intent_getattr_async --> mdc_intent_getattr_async can get both LOOKUP| UPDATE lock.
2. if they are in different MDTs, it needs to get LOOKUP lock on the parent MDT, and UPDATE lock on the child MDT. that said lmv_intent_getattr_async should know parent FID, name, and child FID, i.e. these information should be input into the lmv_intent_getattr_async().

[Lai Siyao]

After some thoughts, I think this may not be necessary, or at least not urgent to support remote entries for statahead now. Because it needs send two RPCs to fetch two locks from different MDT, and furthermore the UPDATE lock may need to be fetched after LOOKUP lock is fetched (to verify it's the same fid), all these is hard to implement asynchronously.

IMHO if statahead doesn't fetch attributes from remote entry, it won't cause any issue, because lookup() will find UPDATE lock is not there, and then it will fetch it synchronously. And directories with many remote entries should be rare case? if so, statahead failure should be rare too.

[Di Wang]

Hmm, this is actually a bug more than an optimization. For remote entry, the LOOCK lock is actually granted by parent MDT, instead of child MDT. And in this function, it sends both LOOKUP and UPDATE lock to the child MDT, and the MDT has no way to know if the FID has local or remote entry, then it might grant both LOCKS, which is wrong of course. So in lmv_intent_getattr_async, it should tell if the name entry is remote entry, then enqueue lookup lock on the parent MDT, and update lock on the child MDT. Or only enqueue update lock on the child MDT. (or maybe skip remote entry, if you think implement this is complicate.)

[Gerrit Updater]

Lai Siyao ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15767
Subject: LU-6578 statahead: drop support for remote entry
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: c1bf57c81dbe18629169436f674e8c44a90d0403

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/15767/
Subject: LU-6578 statahead: drop support for remote entry
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: c0944cc831183a3af9adc7d41cca222b636eec2f

[Peter Jones]

Landed for 2.8