[LU-10248] Need to update PFID of OST objects after layout change

• Type: Technical task
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.11.0
• Affects Version/s: Lustre 2.11.0
• Labels: FLR
• Assignee: WC Triage
• Reporter: Jinshan Xiong (Inactive)

Description

MDT should update PFID information to OST objects after layout swap, split, and merge. However, a protocol should be defined to make this correct. Fanyong proposed to use synchronous OUT setxattr. However, I tend to think it would be better to use llog as SETATTR and DESTROY RPC.

This problem has been existing for really long time since Lustre 2.4. LFSCK could fix this problem but it's better to have a mechanism to solve this kind of problem because there will be more and more similar problems.

Issue Links

• is related to: LU-2677 Adding LMA to OST object
• is related to: LU-3128 filter_fid on OST not updated during layout swap
• is related to: LU-9771 FLR1: Landing tickets for File Level Redundancy Phase 1

Comments

[Jay Lan (Inactive)]

If the work on #30635 is complete, can we land it to b2_10?

[Gerrit Updater]

Minh Diep ([e-mail]) uploaded a new patch: https://review.whamcloud.com/30635
Subject: LU-10248 mdd: set PFID for swap and merge layout
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: 8d034f5aa4794d4dcd761b3e5ba2537995cb4e5d

[Peter Jones]

Is this task complete with the recent landing to master?

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/30292/
Subject: LU-10248 mdd: set PFID for swap and merge layout
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 4d534365ab214e28452c54fd2e0d4781e2f290d6

[Nathan Dauchy (Inactive)]

LU-10349 created for NASA-specific debugging efforts

[Peter Jones]

It really seems like it would be better to transfer the NASA discussion to its own ticket rather than tacking on the end of this ticket to track part of the FLR implementation.

[nasf (Inactive)]

ndauchy, what is your Lustre version?

[nasf (Inactive)]

There is known issue about the repaired_inconsistent_owner, there were also a lot of unexpected repaired_inconsistent_owner in your former logs. They are not the real inconsistency, please ignore them temporarily. On the other hand, as you can see, the Lustre debug logs were overwritten because of those fake repaired_inconsistent_owner information, as to the useful repaired_unmatched_pair logs were lost.

There are two choices:
1) Run layout LFSCK again without "dryrun" option, that will repair the inconsistency directly. But because of too many repaired_inconsistent_owner information, we may cannot know what to be fixed.
2) Keep the inconsistency there. According to your former logs, there are about 283 unmatched MDT-object and OST-object pairs. These unmatched pairs will NOT affect the normal system access as described in the comment:
https://jira.hpdd.intel.com/browse/LU-10248?focusedCommentId=215286&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-215286

I will work on the fake inconsistent owner issue, once done, you can apply related patch(es) and run layout LFSCK again.

[Nathan Dauchy (Inactive)]

Redid the dry run and it reported a lot more than 283 errors! Commands I used are in the uploaded lfsck_2017-12-06-n.txt file, results in the other files should be evident. Please advise.

[nasf (Inactive)]

repaired_unmatched_pair: 283

The layout LFSCK detected 283 unmatched MDT-object and OST-object pairs. Two choices:
1) Run layout LFSCK again without "dryrun" option, that will repair the inconsistency directly.
2) To be safe, enable "lfsck" debug log on the MDT, then re-run dryrun mode layout LFSCK again. After complete, dump the Lustre kernel debug logs on the MDT, that will contain the found inconsistencies. Please ONLY enable "lfsck" debug log to avoid log buffer full and overwritten.