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