[LU-3423] Create LFSCK II Test Plan and attach to Jira ticket

• Type: Technical task
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.6.0
• Affects Version/s: Lustre 2.6.0
• Assignee: nasf (Inactive)
• Reporter: Jodi Levi (Inactive)

Description

Create the test plan for all of LFSCK Phase II and attach to the Jira ticket so that the test engineers know how to test the feature for the release.

Comments

[James Nunez (Inactive)]

Here are the results for the LFSCK Phase II test plan. I plan to add past results to and clean up the presentation of results in this document.

[Jodi Levi (Inactive)]

James' questions have been answered and the test plan does not need to be updated at this point.

[nasf (Inactive)]

The new options "-c" has been tested in the sanity-lfsck.sh test_14/test_18; the new options "-o" has been tested by the sanity-lfsck.sh test_18. They are part of the test plan 1.1)

LFSCK II test plan only needs to cover layout LFSCK, not necessary for namespace LFSCK which has already been done in LFSCK 1.5

Currently, the LFSCK use single async OUT RPC to repair the inconsistency except the orphan handling. Means in spite of dangling reference or unmatched MDT-OST pairs or multiple references or inconsistent owner, they should not affect the repairing performance much. So I select the dangling reference case in the lfsck-performance.sh, which is easy to be simulated. I do not think we need to test all kinds of different inconsistency performance unless we have strong requirement and enough time to do that.

[James Nunez (Inactive)]

With recent patch landings to LFSCK, there are a few more options to choose from. Should we incorporate some of these into the existing test plan?

All of the new options need to be tested, but for for any of the existing tests, that revolve around performance, do we want to :
Create lost OST-objects (-c)?
Handle orphan objects (-o)?
What type should we run namespace, layout or both?

Since XATTR_NAME_FID does not exist, in test 2.2, is setting fail_loc to OBD_LFSCK_UNMATCHED_PAIR* or OBD_LFSCK_INVALID_PFID just as good or will repairing different failures cause dramatically different performance results? Is LFSCK_DANGLING preferred?

[Jodi Levi (Inactive)]

The test plan needs to be updated based on changes made to the functionality since the plan was written. James Nunez has the details. I will ask him to provide in this ticket.

[Jodi Levi (Inactive)]

Sorry if the mention of the internal links in the Test Plan Template caused confusion. We will avoid using those links in any actual test plans. Please let me know if you see any of these links in actual test plans, and I will get it corrected.
Thank you!