[LU-3595] Repair unreferenced OST-object

• Type: Technical task
• Resolution: Duplicate
• Priority: Major
• Assignee: nasf (Inactive)
• Reporter: Richard Henwood (Inactive)

Description

During the second-stage scanning, the orphan OST-objects will be repaired. The MDT will iterate over all of the unreferenced OST-object FIDs and verify that the corresponding parent MDT-object FID does not exist. By this time, the first-stage MDT scanning will have registered the parent FID for any MDT-objects that still exist, so OST-objects without a parent MDT-object FID could be cleaned up immediately or a new FID allocated for them. If the parent MDT-object FID does not exist, then depending on administrator policy for LFSCK the MDT-object will either be recreated in lost+found with a default layout, or the OST object will be destroyed.

LFSCK will create a new file (MDT-object) as lost+found/MDTnnnn/[parent MDT-object FID] and using the same UID/GID as the orphan OST-object. If the MDT-object FID does exist (or was just created) and there is an empty slot (or a newly-created object) at the OST-object index in the layout of the parent MDT object, the OST-object will be inserted into the layout. The logic will be as follows:

1. If the MDT-object exists, but related layout EA slot is occupied by another OST-object, then check whether it is new created OST-object for fixing dangling reference or for fixing multiple referenced OST-object case.
   1. If yes and nobody modified the new created OST-object, then destroy the new created OST-object on the OST, and update the MDT-object layout EA with the given unreferenced OST-object.
   2. Otherwise, it will be kept under lost+found/MDTnnnn. It is the administrator's duty to process it manually.
2. The MDT-object is there, but related stripe information is lost. The LFSCK will update the MDT-object layout EA with the specified stripe information.
   1. If the given stripe offset exceeds current layout EA tail, then needs to extend the layout EA, and put the given stripe information at specified slot. If there are gaps in front of the new stripe slot, then fill them will NULL entries.
   2. If related slot in the layout EA has been filled with a NULL entry, that means the MDT-object layout EA has been extended by the LFSCK in former repairing, then just replace the NULL entry with the given stripe information.
3. Former allocated MDT-object is lost. The LFSCK will generate the layout EA according to the index of the orphan OST-objects. If the layout EA is not completed, means some stripe slots may be empty, then fill as dummy entries. And then create new file with the given MDT-object FID (indicated by the orphan OST-object's file name). Because we only know the MDT-object's FID, but not the file name, it will be created under lost+found/MDTnnnn/[parent MDT-object FID]. If multiple orphan OST-objects claim the same MDT-object and the same stripe index, then only one will be merged, the others will be kept under lost+found/MDTnnnn/. The administrator can process the others later manually.

To re-generate MDT-object layout, the LFSCK needs to know the stripe-size/stripe-pattern. Currently, only the stripe index is stored in the OST-object. So the LFSCK will use the default values (currently 1MB/ LOV_PATTERN_RAID0) to re-generate the MDT-object layout. It may be not correct, but better than do nothing. For the files with replica copies, it is out the scope of LFSCK phase II, and will be handled in the scope of those projects.