Previously we were automatically adjusting pgp_num_target on a
pg_num_target change *only* when decreasing pg_num. Instead, make
pgp_num (continue to) track pg_num if it currently matches. If it ever
is set differently than pg_num, leave it different (unless/until it
matches again).
This is still slightly weird, but I think in practice it is good enough.
In the rare case that the admin manually sets pgp_num to something
different than pg_num, they probably won't also be using automagic
pg_num adjustment that might make them match and start tracking again.
Signed-off-by: Sage Weil <sage@redhat.com>
return -EPERM;
}
}
- // set target; mgr will adjust pg_num_actual later
- p.set_pg_num_target(n);
- // adjust pgp_num_target down too (as needed)
- if (p.get_pgp_num_target() > n) {
+ // set targets; mgr will adjust pg_num_actual and pgp_num later.
+ // make pgp_num track pg_num if it already matches. if it is set
+ // differently, leave it different and let the user control it
+ // manually.
+ if (p.get_pg_num_target() == p.get_pgp_num_target()) {
p.set_pgp_num_target(n);
}
+ p.set_pg_num_target(n);
} else if (var == "pgp_num_actual") {
if (p.has_flag(pg_pool_t::FLAG_NOPGCHANGE)) {
ss << "pool pgp_num change is disabled; you must unset nopgchange flag for the pool first";