Details
-
Improvement
-
Resolution: Unresolved
-
Medium
-
None
-
None
-
None
-
3
-
9223372036854775807
Description
OSP is not able to use IR notification because OSP setup happens after IR processing:
[ 2854.601231] Lustre: 64350:0:(mgc_request.c:1449:mgc_apply_recover_logs()) mgc MGC192.168.56.110@tcp: cannot find obdname lustre-OST0000-osc-MDT0000 [ 2854.605044] Lustre: 64350:0:(mgc_request.c:1449:mgc_apply_recover_logs()) mgc MGC192.168.56.110@tcp: cannot find obdname lustre-OST0001-osc-MDT0000 [ 2854.632094] Lustre: 65436:0:(osp_dev.c:1095:osp_init0()) Starting OSP lustre-OST0000-osc-MDT0000 [ 2854.692742] Lustre: 65436:0:(osp_dev.c:1095:osp_init0()) Starting OSP lustre-OST0001-osc-MDT0000
To make OSP aware of IR changes a new approach is needed.
Initial idea is to maintain per-MGC NID tables caching IR results, and OSP initialization to use this MGC NID table for connection setup. E.g. OSP (and other services?) can query MGC for fresh IR info, and MGC decides either to re-read it from server or use local cached copy if any.
Alternative is to rework setup to process IR llog after OSP (not sure if that is less work and even possible)
The main difficulty here is that new functionality replaces old one, so it requires more review/test cycles to make sure nothing is broken. I mean it can't be enabled in some experimental mode or turned on/off by request.