]> git.apps.os.sepia.ceph.com Git - ceph.git/commit
mon/OSDMonitor: do not mark newly created OSDs OUT
authorSage Weil <sage@newdream.net>
Mon, 22 Feb 2021 23:48:14 +0000 (18:48 -0500)
committerSage Weil <sage@newdream.net>
Wed, 24 Feb 2021 19:55:03 +0000 (14:55 -0500)
commitc8f021cb85b4375faf91af1d580dc8e2e8669395
treec2a803b3b13b5add50c132f276d36bc8f72cbe3a
parenta3591378a59c621ac597987facb3fb30707c218f
mon/OSDMonitor: do not mark newly created OSDs OUT

Currently, new OSDs are marked OUT.

This behavior appears to date back all the way to the 'osd new' command
in c9e6cac1cfae73cc4bce4a995ed2bba5dc85ae4b, and for 'osd create' from
118f081b3c64bc36a8b9825e3373587a334c672b.  The first commit has no
real explanation, but it presumably inherited it from the second. That
second commit, though, says

    if we are creating an osd which has the same id as a previously
    removed 'in' osd, we should not mark this newly created osd as 'in'

This isn't actually a good idea, however.  If we are creating (or reusing)
a new OSD id, the OSD that starts up will have no data.  So no matter what
there will be a data migration from the before state to the final state.
If we mark the osd OUT when the osd id is allocated but before the OSD
starts up, we'll create a middle state where PGs are mapped to the id (by
virtue of the CRUSH weight) and then remapped away (due to out), creating
a middle state where a bunch of PGs will repeer and maybe data will move.

Instead, we have two cases:

1) If we are reusing a DESTROYED osd id, we should leave the in/out
state the way it was.  This way we still go straight from the before
state to the after state (the osd will mark itself in when it starts up).

2) If we are allocating a new id in do_osd_create(), we want the OSD
to be IN, so there is no middle state.  Unfortunately, we have to work
around apply_incremental() being obnoxious here: it's sloppy implementation
will implicitly set EXISTS by virtue of new_osd_weight (the mark IN part)
before applying the osd_state XOR, so be careful!  (This behavior is
mirrored by the Linux kernel implementation too, thankfully.)

Signed-off-by: Sage Weil <sage@newdream.net>
src/mon/OSDMonitor.cc