fix(channel_reconfig): don't reconfigure the non-IO nexus channel #37
Conversation
Signed-off-by: Diwakar Sharma <diwakar.sharma@datacore.com>
|
With this change, I ran the testcase written under openebs/mayastor#1506 and it passes OK. |
| @@ -170,7 +170,10 @@ extern "C" fn inner_traverse_channel<ChannelData, Ctx>( | |||
| let ctx = TraverseCtx::<ChannelData, Ctx>::from_iter(i); | |||
| let mut chan = IoChannel::<ChannelData>::from_iter(i); | |||
|
|
|||
| let rc = (ctx.channel_cb)(chan.channel_data_mut(), &mut ctx.ctx); | |||
| let mut rc = ChannelTraverseStatus::Ok; | |||
| if chan.thread_name() != "init_thread" { | |||
There was a problem hiding this comment.
This might work for now but seems quite brittle.. we probably better do this properly by using channel specific data. Example: Adding bool io_channel to the NexusChannel perhaps
There was a problem hiding this comment.
Thought that, but perhaps that'd require some hacking because NexusChannel won't be directly accessible here in ffi spdk_rs. Here we only have a generic channel type view.
There was a problem hiding this comment.
Alternatively, I can let this closure call happen irrespective of spdk thread and read the new boolean in the nexus code just before callling chan.reconnect_all(). However, to set that bool to true or false during channel construction we'll again have to rely on spdk thread name I guess?
There was a problem hiding this comment.
or better, can get the id of current thread by spdk_thread_get_id() using spdk_rs::Thread abstraction of spdk_thread, and if id is 1 it's init_thread.
There was a problem hiding this comment.
Deferring the decision to the "rust native" code seems good.
tiagolobocastro
force-pushed
the
develop
branch
2 times, most recently
from
cbc1fea
to
c443473
Compare
The sync qpair connect can race with a async connect during an unplug dynamic reconfiguration event. This can happen on the nexus channel that gets created as part of rebuild on spdk thread
init_thread. Since this nexus channel is not used for normal IO, we can ignore this from reconfiguration. The rebuild IOs can still be served on this and the locked byte ranges will still be safe via other nexus channels, but any other child device add/remove will not disturb this channel via dynamic reconfigure path.