as pg_creatings needs mapping to get the acting_primary osd of the
creating pg, so we can send the pg-create message to it if it subscribes
to this information, mapping should always be available now.
Signed-off-by: Kefu Chai <kchai@redhat.com>
osd will send beacon message to monitor periodically to inform it that
"i am still alive!", previously, monitor use the pg-stats to check the
status of OSD, but since osd will only send pg stat to mgr after
luminous, we use a dedicated msg for this purpose.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this change updates the comment for 7fb3804fb, 97462a3 and e807770,
to reflect the reason why we need to fix latest_full in current code.
as the fix is not a workaround for cuttlefish anymore, it resolves the
issue where
0. mon.c has a latest_full of 5
1. mon.c is shutdown and out of sync with the quorum
2. mon.c starts sync
3. mon.c now has osdmap[31..50], and the latest_full is still 5.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* PGMapUpdater::check_down_pgs(): pass a const reference to pgmap
instead of a pointer
* PGMapUpdater::register_new_pgs(): pass a const reference to pgmap
instead of a pointer
Signed-off-by: Kefu Chai <kchai@redhat.com>
Make Device::last_poll_dev `unsigned` - it could overlap and should not
be negative.
Also, add missing initialization.
Change-Id: I558f02292ae4f5d1ce48d9bcda5047d382604237
Signed-off-by: Amir Vadai <amir@vadai.me>
Setting RDMA_DEBUG to 1, will enable debug prints for every ibv_*
function called.
This makes it easier to debug RDMA issues.
Issue: 995322
Change-Id: I49d327d5d4386b44264f5619d50f2dbc7d76dcae
Signed-off-by: Amir Vadai <amir@vadai.me>
Currently the PGMap may register the new pg in multiple places: the
mgr or mon, and the timestamp is when the mon or mgr gets around to
recording it into its PGMap. Make this deterministic by using the OSDMap
mtime (which is when the PG was *actually* created).
This fixes a problem where the pg create command has one timestamp (from
the mon) and the pgmap on the mgr has another, so an observer will see the
last_scrub_stamp (and other timestamps) change when nothing has actually
happened.
Signed-off-by: Sage Weil <sage@redhat.com>
If we get as far as authenticating and have no MgrMap that implies the
mon didn't provide us one (despite our request) and we have no access to
the mgr at all.
Signed-off-by: Sage Weil <sage@redhat.com>
Perfcounters can go away; deal with it. This collapses
into a single loop, but it means that the mgr might
stop getting certain counters without explicit
notification.
Signed-off-by: Sage Weil <sage@redhat.com>