mds: fix cond that prevents sending MLock messages to starting MDS #21577
Conversation
|
This is not quite right. That actual fix is to change |
src/mds/Locker.cc
Outdated
| @@ -890,7 +890,7 @@ void Locker::eval_gather(SimpleLock *lock, bool first, bool *pneed_issue, list<M | |||
| return; | |||
| } | |||
|
|
|||
| if (!mds->is_cluster_degraded() || | |||
| if (!mds->is_cluster_degraded() && | |||
| mds->mdsmap->get_state(auth) >= MDSMap::STATE_REJOIN) { | |||
There was a problem hiding this comment.
it's not wrong. !mds->is_cluster_degraded() check is an optimization, it avoids checking target mds' state for each message
Fixes: http://tracker.ceph.com/issues/23812 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
|
@ukernel PTAL. It looks to fix the problem in my testing. Please also look at #18278 (comment) |
|
The root cause is that mds discovers root inode when it's still in starting state. It should handle lock message after it get replica of root inode. I think a better to discover root inode when mds is active. (just like the code for creating new mds rank). The subtle part is that, when mds is in starting state, it needs to load dirfrag of its mdsdir, then creates a new log segments |
|
@ukernel, that may be the cause but does it need fixed if we do this patch? It seems to me that having one rank in up:starting is actually a degraded state since the rank is unavailable which could prevent lock processing |
|
Actually what I said makes no sense since a Still, I feel "degraded" might not be the right thing here though and perhaps we just need a different term to represent that the MDS cluster has ranks which are creating/starting/recovering. |
|
I think degraded is OK for cluster with failed or recovering mds. If we make mds not discover inode when it's in creating/starting state, I think we don't need to create new state for cluster with creating/starting mds. |
|
Sure! |
Fixes: http://tracker.ceph.com/issues/23812
Signed-off-by: Patrick Donnelly pdonnell@redhat.com