[LU-5767] LFSCK 3: replace LFSCK RPC with normal OUT RPC to create orphan parent on remote MDT

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.7.0
• Affects Version/s: Lustre 2.7.0
• Labels: HB
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: nasf (Inactive)

Description

When the namespace LFSCK tries to repair the missing name entry, means inserting the lost name entry back to its parent directory, it may find that the parent MDT-object is also lost. Under such case, the namespace LFSCK will firstly create the missing parent MDT-object as an orphan and insert into the .lustre/lost+found/MDTxxxx/ directory with the name:

${FID}-P-${conflict_version}.

Then insert the lost name entry into the orphan parent according to the MDT-object's linkEA.

Currently, the namespace LFSCK uses LFSCK RPC to handle the case of creating orphan parent MDT-object on remote MDT. It is not the normal way for cross-MDTs modification that usually will be handled via OUT RPC. Please refer to the comment on gerrit for more discussion:

http://review.whamcloud.com/#/c/11391/28/lustre/lfsck/lfsck_namespace.c,cm

Comments

[Peter Jones]

Landed for 2.7

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/13172/
Subject: LU-5767 lfsck: use OUT RPC to create remote orphan parent
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 58ddddb5386951f05c52b8e6f98fcfa8139097d5

[nasf (Inactive)]

This patch should be landed to master before Lustre-2.7 release to avoid interoperability issues in future.

[Gerrit Updater]

Fan Yong ([e-mail]) uploaded a new patch: http://review.whamcloud.com/13172
Subject: LU-5767 lfsck: use OUT RPC to create remote orphan parent
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 35a902c02e4eb6f71bcd820e3ea5904f597df9c6

[nasf (Inactive)]

I prefer to land it before Lustre-2.7 release. I will handle it as bug fixing after 2.7 feature frozen.

[Andreas Dilger]

Alex, Fan Yong, is this supposed to be fixed for 2.7 or can it land in 2.8? It looks like it concerns the wire protocol.

[nasf (Inactive)]

On concern: if we does not resolve the inconsistency related with the .lustre/lost+found/MDTxxxx at the LFSCK beginning, then how the layout LFSCK can handle the orphan OST-objects after that? The layout LFSCK can run independently with namespace LFSCK, but it can neither realise that the object for .lustre/lost+found/MDTxxxx may be orphan, nor repair such inconsistency.