mon: always reply mdsbeacon

the MDS (Beacon) is always expecting the reply for the mdsbeacon messages from
the lead mon, and it uses the delay as a metric for the laggy-ness of the
Beacon. when it comes to the MDSMonitor on a peon, it will remove the route
session at seeing a reply (route message) from leader, so a reply to
mdsbeacon will stop the peon from resending the mdsbeacon request to the
leader.

if the MDSMonitor re-forwards the unreplied requests after they are
outdated, there are chances that the requests reflecting old and even wrong
state of the MDSs mislead the lead monitor. for example, the MDSs which sent
the outdated messages could be dead.

Fixes: #11590
Signed-off-by: Kefu Chai <kchai@redhat.com>
(cherry picked from commit b3555e9c328633c9e1fbc27d652c004b30535e5b)

diff --git a/src/mon/MDSMonitor.cc b/src/mon/MDSMonitor.cc
index a4f87371b0ce1806f4bfe1bfe2511523e5b2f4a0..4cf26cd41b91a5a7cf30944264579eeeaf66c80a 100644 (file)
--- a/src/mon/MDSMonitor.cc
+++ b/src/mon/MDSMonitor.cc
@@ -318,7 +318,7 @@ bool MDSMonitor::preprocess_beacon(MMDSBeacon *m)
     goto ignore;
   }
   // is there a state change here?
-  if (info.state != state) {    
+  if (info.state != state) {
     // legal state change?
     if ((info.state == MDSMap::STATE_STANDBY ||
         info.state == MDSMap::STATE_STANDBY_REPLAY ||
@@ -592,8 +592,14 @@ void MDSMonitor::_updated(MMDSBeacon *m)
   if (m->get_state() == MDSMap::STATE_STOPPED) {
     // send the map manually (they're out of the map, so they won't get it automatic)
     mon->send_reply(m, new MMDSMap(mon->monmap->fsid, &mdsmap));
+  } else {
+    mon->send_reply(m, new MMDSBeacon(mon->monmap->fsid,
+                                     m->get_global_id(),
+                                     m->get_name(),
+                                     mdsmap.get_epoch(),
+                                     m->get_state(),
+                                     m->get_seq()));
   }
-
   m->put();
 }