[LU-5669] LFSCK 5: Distinguish dangling name entry from corrupted name entry

• Status: Open
• Project: Lustre
• Affects Version/s: Lustre 2.7.0
• Type: Improvement
• Priority: Minor
• Reporter: nasf (Inactive)
• Assignee: nasf (Inactive)
• Resolution: Unresolved
• Severity: 3

Description

During the first-stage scanning, if the namespace LFSCK finds the name entry that references a non-existing MDT-object, then it is possible that:

1) It is a dangling name entry. Under such case, according to our design, the LFSCK will repair as following:

1.1) By default, the LFSCK will report the inconsistency without re-creating the lost MDT-object.

1.2) If the administrator requires to re-create the lost MDT-object when start the LFSCK, then the LFSCK will re-create the lost MDT-object.

2) It may be a bad name entry that contains a bad FID. Two possible situations: assume it is the entry_A, and the original FID in the name entry_A is for the obj_B, but current FID is for the obj_C:

2.1) Only the FID in the name entry_A is corrupted. Then as the LFSCK processing in the second-stage scanning, the LFSCK will find the obj_B that back references the name entry_A via its linkEA.

2.2) Both the name and the FID in the entry_A are corrupted. Then even though the LFSCK find the obj_B in the second-stage scanning, it still cannot know the relationship between the name entry_A and the obj_B.

From the LFSCK view, during the first-stage scanning, it cannot distinguish whether it is case 1) or case 2). Currently, we assume it is the case 1), and repair it as 1.1) or 1.2) according to the LFSCK start options. But if it is the case 2.1), and has been handled as 1.2), then the LFSCK created the obj_C by wrong.

To resolve above trouble, in the second-stange scanning, when the LFSCK finds the original obj_B that back references the name entry_A via its linkEA, the LFSCK will check whether someone has ever modified the obj_C after the creating: if not, it will update the FID in the name entry_A to reference the obj_B, and destroy the obj_C; otherwise, to keep the new data in the obj_C, the LFSCK will create a new name entry under lost+found to reference the obj_B.

Current solution looks reasonable, but it maybe confuses the application that read-accessed the name entry_A during the LFSCK. It will find the target MDT-object has been changed from obj_C to obj_B.

To avoid such confusion, the LFSCK should not re-create the lost MDT-object until it is sure that the name entry_A is dangling, not bad name entry. In theory, the LFSCK can know that after the second-stage double scanning finished successfully (all known linkEA entries have been verified), and it needs to record all related name entries in the tracing file (or another name tracing file). But even though the LFSCK did that, if it is the case 2.2), then the LFSCK still cannot distinguish it from dangling name entry. So there are still some troubles to be resolved.

On the other hand, can the application regard the case of obj_C replaced by obj_B as "unlink obj_C and create obj_B with the same name"?

Comments

[nasf (Inactive)]

Sirs, any idea about distinguishing dangling name entry from corrupted name entry? Especially consider the case 1) and the case 2.2).

[Andreas Dilger]

Depending on the corruption, it should be possible to verify if the FID of the object is valid or not. Since the SEQ is a 64-bit value, if the object FID does not match any object it is possible to look up the FID in the FLDB to see if it is valid or not. This would give LFSCK some idea whether the FID is corrupted in either the dir entry or the LMA. Similarly, it could compare the LMA FID against the LOV EA FID to see if they match.

[nasf (Inactive)]

But in spite of how we check the FID, we still cannot know whether the name string in the name entry is corrupted or not. If we cannot know that, then we cannot distinguish it from the dangling name entry or corrupted name entry. Such situation exists in theory.

[Andreas Dilger]

In theory, yes, but in practice there are 2^64 FID SEQ values, and at most a few million or billion would be used, so in almost all cases it will be possible to detect bad FIDs.

[nasf (Inactive)]

1) If the FID in the name entry is insane, then regard the name in the entry as invalid, remove the name entry. If some MDT-orphan back references the removed name entry, the LFSCK will re-insert the name entry. (One trouble is that if the LFSCK removed the name entry, but some MDT-object back reference it, before the LFSCK re-inserting the name entry back, some other may re-use the name, under such case, the original MDT-object will become orphan, and be added to the global lost+found.)

2) If the FID in the name entry is sane, then the name in the entry is still possible corrupted, but since we cannot distinguish it from normal cases, just assume it is valid, say that is the FID_A, then LFSCK re-create the lost MDT-object_A. Two possibilities:
2.1) the FID_A in the name entry is really valid, then above processing is enough.
2.2) if the FID_A in the name entry is corrputed as a valid one, and some other MDT-object_B with FID_B back reference the name entry, then when the LFSCK find the orphan MDT-object_B, the LFSCK will check whether the MDT-object_A is created by LFSCK for repairing dangling name entry (via check ctime == 0 or not, if someone changed it after LFSCK re-created it, ctime will be changed as non-zero). If yes, replace FID_A in name entry as FID_B, and destroy the MDT-obejct_A; otherwise, the MDT-object_B will be added to global lost+found if has no other valid linkEA.