[LU-4876] LFSCK remove entry from /REMOTE_PARENT_DIR if MDT-object name reside on the same MDT after migration

• Type: Bug
• Resolution: Unresolved
• Priority: Major
• Labels: dne2 lfsck
• Severity: 3
• Assignee: Lai Siyao
• Reporter: nasf (Inactive)

Description

When migrate directory MDT-object_A's metadata from MDT_x to MDT_y, all its children name entries needs to be moved to MDT_y. If some name entry originally referenced a remote MDT-object_B which was linked under "/REMOTE_PARENT_DIR" with a dummy name entry on MDT_y, but after the migration, the MDT-object_B and its new name entry resides on the same MDT_y, then the dummy entry for the MDT-object_B should be removed from "REMOTE_PARENT_DIR/" iff there are no links remaining on that MDT.

Issue Links

• is related to: LU-15383 DNE directories not connected to REMOTE_PARENT_DIR
• is related to: LU-5985 LFSCK 5: remove dummy name entry from /REMOTE_PARENT_DIR if the MDT-object and its name entry reside on the same MDT
• is related to: LU-15388 Wrong dotdot FID parameter for osd_add_dot_dotdot()
• is related to: LU-10329 DNE3: REMOTE_PARENT_DIR scalability
• is related to: LU-14168 e2fsck should avoid moving files into lost+found
• is related to: LU-4684 DNE3: allow migrating DNE striped directory

Comments

[Andreas Dilger]

I've also seen a few cases where e2fsck complains about hard-linked directories in REMOTE_PARENT_DIR:

Entry '0x200007168:0x4af:0x0' in /REMOTE_PARENT_DIR (1119354881) is a link to directory /ROOT/.lustre/lost+found/MDT0000/[0x200005233:0x89:0x0]-O-0 (8938935).
Clear? yes

It looks like e2fsck fixes this by removing the entry from REMOTE_PARENT_DIR, but LFSCK shouldn't get into this situation in the first place.

[Andreas Dilger]

Artem, it just looks that way because of the e2fsck messages:

Pass 5: Checking group summary information
Free blocks count wrong (32862, counted=32853).
Free inodes count wrong (99721, counted=99718).

which usually means that the filesystem is mounted, or at least was not unmounted cleanly.

[Artem Blagodarenko (Inactive)]

adilger Thanks for idea. I believe the target was not mounted during fsck. I used CLEANUP=cleanupall option.
laisiyao will try with patches from LU-4684. Thanks.

[Andreas Dilger]

Artem, I also noticed this, but it was fixed (at least for 2.12) by unmounting the MDT and running e2fsck on the unmounted device. While it was mounted, the change was only in the journal and did not show up in the filesystem itself.