Currently, LFSCK use two phases scanning to guarantee all the inconsistency can be handled completely and efficiently.
1) The first-stage scanning
There is a LFSCK main engine on every MDT/OST that involves the LFSCK. During the first-stage scanning, each LFSCK main engine scans its local device via low layer object-table based iteration that uses linear scanning method and guarantees that all the objects related with this server (MDT or OST) will be checked. But sometimes, the LFSCK cannot know whether the object is inconsistency or cannot know how to repair the inconsistency until the first-stage scanning finished. Then the LFSCK needs the second-stage scanning.
2) The second-stage scanning
During the first stage-scaninng, some uncertain objects will be recorded, depends on the LFSCK type.
2.1) For namespace LFSCK, the object will multiple hard-links, or with multiple linkEA entries, or with remote parent, and so on, will be recorded in the namespace LFSCK tracing file. And then, in the second-stage scanning, the namespace LFSCK will scan the objects in the namespace LFSCK tracing file in turn and handle the uncertain inconsistency.
2.2) For layout LFSCK, the OST-objects that are not referenced by any MDT-object are recorded in a bitmap. When the LFSCK moves to the second-stage scanning, the OST-objects in such bitmap will be re-scanned to check whether they are really orphans or not.
I think it would be appropriate to describe these phases in the "Description" sections of the "LFSCK status of namespace via procfs" and "LFSCK status of layout via procfs" sections.