Bug #17259: multimds: ranks >= max_mds may be assigned after reducing max_mds - CephFS - Ceph

Actions

Copy link

Bug #17259

closed

multimds: ranks >= max_mds may be assigned after reducing max_mds

Added by Patrick Donnelly over 7 years ago. Updated about 5 years ago.

Status:

Won't Fix

Priority:

Normal

Assignee:

Patrick Donnelly

Category:

Target version:

% Done:

Source:

Development

Tags:

Backport:

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

multimds

Component(FS):

MDSMonitor

Labels (FS):

multimds

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

I'm not sure if this is really a problem or not but I noticed in:

http://pulpito.ceph.com/pdonnell-2016-09-10_15:15:29-multimds:thrash-master---basic-mira/408387

We can have a sequence:

max_mds 9 -> 8
deactivate rank 7 (mds.b)
kill rank 8 (mds.d)
mds.b comes back and is assigned rank 8 (not 7!)

As long as max_mds is not exceeded, maybe this isn't an issue. There may be assumptions in the code that assume `rank < max_mds`?

I'm also wondering if it's possible that rank 8 is replaced regardless of max_mds. I'm checking that possibility by adding standbys to a new test run:

http://pulpito.ceph.com/pdonnell-2016-09-11_17:59:46-multimds:thrash-master---basic-mira/

Actions

Copy link

Updated by John Spray over 7 years ago

Yeah, ranks are assigned out of the 'in' set rather than sequentially, so if you deactivate one in the middle of the range then that rank won't get re-used until the in set is smaller than max_mds again.

I think this is completely legal, but it does make me wonder if we should force people to deactivate ranks in order to maintain a contiguous set of ranks. I guess that would make deactivating many at once awkward, unless we permitted stopping many at once, but didn't let each one finish stopping until it saw an mdsmap where all higher ranks had already stopped.

Actions

Copy link