[LU-16159] remove update llog files after recovery abort

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.16.0
• Labels: llog recovery
• Severity: 2
• Assignee: Lai Siyao
• Reporter: Lai Siyao

Description

Once recovery is aborted, the existing update logs should be removed, because they are used for recovery only, and if it's corrupt, or inaccessible, if they are kept there after recovery abort, the next recovery will meet with the same issue again, besides, the log file size may become large, retrieving them in recovery may lead to recovery timeout.

Besides this, in LOD device initialization, it should do some sanity check for all update logs on it, if the log file is not accessible (e.g. OI mapping mismatch, which may lead to recovery timeout too), delete the log file FID from update catalog (do not delete this file at the moment because it's inaccessible) so that the log file is not visible to others.

Issue Links

• is related to: LU-16398 ost-pools: FAIL: remove sub-test dirs failed
• is related to: LU-7011 Kernel part of llog subsystem can do self-repairing in some cases
• is related to: LU-17365 steady LOD update llog connection
• is related to: LU-16336 LFSCK should fix inconsistencies caused by recovery abort
• is related to: LU-15934 client refused mount with -EAGAIN because of missing MDT-MDT llog connection
• is related to: LU-16335 "lfs rm_entry" failed to remove broken directories

Comments

[Peter Jones]

Patches already landed are what will be in 2.16.

[Gerrit Updater]

"Etienne AUJAMES <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51224
Subject: LU-16159 osp: destroy should not overtake writes
Project: fs/lustre-release
Branch: b2_15
Current Patch Set: 1
Commit: acfee963c6999785afdd3b25c83015695099a3b9

[Gerrit Updater]

"Etienne AUJAMES <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51223
Subject: LU-16159 lod: cancel update llogs upon recovery abort
Project: fs/lustre-release
Branch: b2_15
Current Patch Set: 1
Commit: a544f6c69fe4b2eb81f4b05581654325ecc96f93

[Andreas Dilger]

Is there anything left for this ticket, or can it be resolved?

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49787/
Subject: LU-16159 osp: destroy should not overtake writes
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 5a5bd5b4dafaf252c641b8afd2cd809de7384f4f

[Xing Huang]

"Alex Zhuravlev <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49787
Subject: LU-16159 osp: destroy should not overtake writes
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0e0993837d0e13bd31d53daea04e7259be6c1c4c

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49633
Subject: LU-16159 tests: cleanup replay-single code style
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: cb4e810ddfb11aab30ea6ad6b40ff371c04ddac1

[Andreas Dilger]

Reopening this so that it is being tracked for 2.16 due to latest patch.

[Gerrit Updater]

"Lai Siyao <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49526
Subject: LU-16159 target: race in update log cancel
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 983a53137bfd26e6baaba4575a9dbb379e358b76

[Andreas Dilger]

But won't that defeat the whole purpose of the fix? Could something else be done, like forcing rollover to new logs and then cancelling the old logs, so that in-use logs are not removed?