[LU-6380] OI scrub should be able to scan the update log file before replay

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.8.0
• Affects Version/s: Lustre 2.8.0
• Labels: dne2
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: Di Wang

Description

Right now, OI scrub is started after recovery, which might cause problem for MDS-MDS recovery. Because it relies on the update log, which regular FID file, mapped through OI. i.e. after MDT backup and restore, recovery thread will not be able to retrieve the update log file correctly, because OI scrub is not running until recovery finished.

So we probably should let OI scrub fix some key file first like update log, then start recovery.

Issue Links

• is related to: LU-3534 async update cross-MDTs

Comments

[nasf (Inactive)]

The patch has been landed to master.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/15192/
Subject: LU-6380 scrub: handle update_log during initial scrub
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 342149e654cdde71b34ad0148749adc7cf9f7cfe

[Gerrit Updater]

Fan Yong ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15192
Subject: LU-6380 scrub: handle update_log during initial scrub
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 6c50004f61c95241fa5f026e540e3172589f06ba

[Andreas Dilger]

Please also include a test for OI Scrub rebuilding OI files for an MDT in recovery.

[nasf (Inactive)]

Currently, the initial OI scrub will fix some key files before recovery, such as ROOT, .lustre, and so on. These files either have known FID or not care about what the FID is. As for the update log, it is new for DNE2, we can make the initial OI scrub to handle them before recovery. But because the update log's FID is stored as its name, then the initial OI scrub needs to handle them specially.