SIGN IN SIGN UP

osd/PeeringState: don't clear PG rebuild latch on same-primary interval restart

clear_primary_state() unconditionally reset the rebuild-time latch
(rebuild_start_time, rebuild_base_recovered, rebuild_had_redundancy_loss),
and it runs on every start_peering_interval() call, including routine
acting-set churn (e.g. a backfill peer joining or leaving) that leaves
the primary OSD unchanged. On a PG that stays degraded/recovering
across several such interval restarts under the same primary, the latch
was wiped before prepare_stats_for_publish() ever reached the
"recovered" branch, so pg_rebuild_duration/max_secs/min_secs stayed at
0 despite a real, ongoing rebuild.

Also, a publish landing in a narrow window involving a peering-interval
restart, where clear_primary_state() wipes acting_recovery_backfill/missing_loc
before peering repopulates them, sees num_objects_degraded == 0 and no
DEGRADED/UNDERSIZED bit set. Publish stats can in this situation prematurely
conclude that a recovery is complete. This can truncate the PG
rebuild duration incorrectly. This is fixed by requiring the PG state to be
PG_STATE_ACTIVE to filter out that transient situation.

Only clear the latch in start_peering_interval() when the primary role
actually changes across the transition (!(was_old_primary &&
is_primary())). A genuine primary -> replica handover (or vice versa) still
discards the latch, since a stale start time must not be reused across a role
change.

Tests:
- Add a new unit test that reproduces the latch already set + interval restart
  + primary unchanged condition and confirms that the in-progress latch time
  is not cleared.

- Harden an existing standalone test to deterministically reproduce the
  exact bug sequence instead of leaving it to timing. The previous version
  only asserted pg_rebuild_duration.avgcount>=1 and sum>0 after a full
  recovery cycle. Those checks pass even under the clear_primary_state()
  latch bug

Fixes: https://tracker.ceph.com/issues/79028
Signed-off-by: Sridhar Seshasayee <sridhar.seshasayee@ibm.com>
S
Sridhar Seshasayee committed
6dcdaa0e74a2cd425176d84ff378214098d7ae70
Parent: e12106a