add a new message type MPGCreated. osd is supposed to send this message
to monitor to inform that any pg(s) is created and activated.
Signed-off-by: Kefu Chai <kchai@redhat.com>
OSDMonitor will handle the pg-create subscriptions after luminous.
1. scan new pools to get the pgs to be created
2. send pg creates using the collected pgs
3. trim the creating_pgs using the "created!" messages from OSD.
please note that we need to wait for the OSDMonitor::mapping to be fully
populated, so we cannot scan the incrementa map for creating pgs until
it is applied and accepted by other monitors.
Signed-off-by: Kefu Chai <kchai@redhat.com>
we will access the mon->session_map for sending the osd-pg-creates
messages when finishing osdmapping in OSDMonitor, this could happen in
another thread without the protection of Monitor::lock, or in the same
thread already guarded by Monitor::lock. so instead of changing
Monitor::lock to a recursive lock, a new lock is introduced to protect
session_map.
Signed-off-by: Kefu Chai <kchai@redhat.com>
otherwise subcriptions on peons won't get the creating_pgs notification
mapping updated. we want to send the notification from peons also. and
the notifications should be updated with the updated pg mapping.
Signed-off-by: Kefu Chai <kchai@redhat.com>
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>
