mgr: fix pgp_num vs merge pacer

This condition should only kick in for pgp_num reductions, or else we'll
end up jump to the end instead of slowing down merges.  (For splits, we
don't need to pace like this at all.)

Fixes 76503a1438fa1f166d2c230c73ca8d7b67e6468d

Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit e6113c172523906ee2f5a317ddb358e215d0a448)

diff --git a/src/mgr/DaemonServer.cc b/src/mgr/DaemonServer.cc
index 38143ecc227f8c36e1c0f625919539018840eca8..1a248eebf33aa5fb1f452e905891ef060846a466 100644 (file)
--- a/src/mgr/DaemonServer.cc
+++ b/src/mgr/DaemonServer.cc
@@ -2601,7 +2601,8 @@ void DaemonServer::adjust_pgs()
              }
              dout(20) << " room " << room << " estmax " << estmax
                       << " delta " << delta << " next " << next << dendl;
-             if (p.get_pgp_num_target() == p.get_pg_num_target()) {
+             if (p.get_pgp_num_target() == p.get_pg_num_target() &&
+                 p.get_pgp_num_target() < p.get_pg_num()) {
                // since pgp_num is tracking pg_num, ceph is handling
                // pgp_num.  so, be responsible: don't let pgp_num get
                // too far out ahead of merges (if we are merging).