[LU-18352] Some targets are missing local copy of sptlrpc config

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.17.0
• Severity: 3
• Assignee: Mikhail Pershin
• Reporter: Mikhail Pershin

Description

If several targets are running on the same node, then only the first one getting sptlrpc config from server will have local copy of it.

Problem is in nature of sptlrpc config which is shared between all targets on particular MGC, so the first target fetch it from server and get local copy, but next one find it in memory with cleared cfg_sb and skip local copy creation as have no access to lsi

Possible solution is to update cfg_sb with current target sb when it finds existing config_llog_data

Issue Links

• is related to: LU-17643 Make a local copy of the sptlrpc llog

Comments

[Peter Jones]

Merged for 2.17

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/56609/
Subject: LU-18352 mgc: explicitly create sptlrpc local copy
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 24846bddb405c563b7f92efd4a07e6c445cb44f3

[Mikhail Pershin]

Unfortunately there is no simple solution like update 'sb' and let it go. In that case the same security config would be processed as many times as mount attempts on node, and I'd avoid that to don't mess also with more security related issues caused by that. sebastien is agreed that we must stick with single security config processing for single FS as much as possible.

That means we can't get local copies for all target by ordinary means - when local copy creation is just part of config processing. In general we would need single processing but several config copies. That can be implemented in the following way:

• when sptlconfig is added first it is processed as usual, like it works now
• after first processing, all other mounts which finds that config in memory do call to special 'mgc_sptlrpc_local_copy()'
• it uses new 'sb' and if config still has MGC lock, it does just config llog copy for that target without further processing of that llog again

That doesn't guarantee local copies for all target, as well as that is not guaranteed now, because that depends on availability of remote server, but in general that can remove 'only one target has copy' restriction at least

[Gerrit Updater]

"Mikhail Pershin <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/56609
Subject: LU-18352 mgc: update 'sb' in shared config_llog_data
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 38c157cb0ad9ceb9680e33475650ce5a87e7f358