Project

General

Profile

Actions

Bug #63881

closed

Inaccurate pg splits/merges and pool deletion/creation on OSD mapgap

Added by Matan Breizman about 2 years ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Category:
-
Target version:
-
% Done:

0%

Source:
Development
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
Pull request ID:
Tags (freeform):
backport_processed
Fixed In:
v19.3.0-3579-g25fb8aa671
Released In:
v20.2.0~2449
Upkeep Timestamp:
2025-11-01T01:34:17+00:00

Related issues 2 (2 open0 closed)

Related to RADOS - Bug #57628: osd:PeeringState.cc: FAILED ceph_assert(info.history.same_interval_since != 0)In ProgressMatan Breizman

Actions
Copied to RADOS - Backport #70028: reef: Inaccurate pg splits/merges and pool deletion/creation on OSD mapgapDeferredMatan BreizmanActions
Actions #1

Updated by Matan Breizman about 2 years ago

  • Subject changed from Inaccurate split handling to Inaccurate pg splits/merges on OSD mapgap
  • Assignee set to Matan Breizman
  • Backport set to quincy,reef

When handling MOSDMap with OSDMaps of epochs [first, last] we add each one to `added_maps`.
Later on, we use `added_maps` to calculate the "diff" in terms of pool deletion/creation and pg num changes.
To find the "diff" we compare between each OSDMap to its previous map (See assertion below).
This tracking (of pg_num_history) will be mainly used by OSDService::identify_splits_and_merges.

void OSD::handle_osd_map(MOSDMap *m) { 
  ..
  // check for pg_num changes and deleted pools
  OSDMapRef lastmap;
  for (auto& i : added_maps) {
    if (!lastmap) {
      if (!(lastmap = service.try_get_map(i.first - 1))) {
        dout(10) << __func__ << " can't get previous map " << i.first - 1
                 << " probably first start of this osd" << dendl;
        continue;
      }
    }
    ceph_assert(lastmap->get_epoch() + 1 == i.second->get_epoch());

}

If we can't find the previous map of the first "added_map" - we assume this is the first start of the OSD and we can skip
this iteration.
As a result, we won't check the "diff" between the last epoch of which the OSD was up before the gap (n) to the first added map (m) epoch.
The OSD's information of loaded_pgs on boot may remain stale and cause issues.

int OSD::init()
{
  ..
  osdmap = get_map(superblock.current_epoch);
  set_osdmap(osdmap);

  ..

  // initialize osdmap references in sharded wq
  for (auto& shard : shards) {
    std::lock_guard l(shard->osdmap_lock);
    shard->shard_osdmap = osdmap;
  }

  // load up pgs (as they previously existed)
  load_pgs();

  ..
}

The "previously existed" pgs will be loaded and the `shard_osdmap` will be updated to superblock.current_epoch (n).
When identify_splits_and_merges will be called we will compare between the `shard_osdmap` to m without
maintaining any corresponding changes (deletion/creation of pools and pg splits and merges) throughout maps epochs of [ n + 1, m + 1].

Actions #2

Updated by Matan Breizman about 2 years ago

  • Pull request ID set to 54988
Actions #3

Updated by Matan Breizman about 2 years ago

  • Subject changed from Inaccurate pg splits/merges on OSD mapgap to Inaccurate pg splits/merges and pool deletion/creation on OSD mapgap
Actions #4

Updated by Matan Breizman almost 2 years ago

  • Status changed from New to Fix Under Review
Actions #5

Updated by Matan Breizman almost 2 years ago

  • Related to Bug #57628: osd:PeeringState.cc: FAILED ceph_assert(info.history.same_interval_since != 0) added
Actions #6

Updated by Konstantin Shalygin about 1 year ago

  • Backport changed from quincy,reef to reef
Actions #7

Updated by Konstantin Shalygin about 1 year ago

  • Status changed from Fix Under Review to Pending Backport
  • Source set to Development
Actions #8

Updated by Upkeep Bot about 1 year ago

  • Copied to Backport #70028: reef: Inaccurate pg splits/merges and pool deletion/creation on OSD mapgap added
Actions #9

Updated by Upkeep Bot about 1 year ago

  • Tags (freeform) set to backport_processed
Actions #10

Updated by Matan Breizman about 1 year ago

  • Status changed from Pending Backport to Resolved
  • Backport deleted (reef)

I'm not sure that we should backport this yet as this might be a delicate change which also involves a refactor.
@Radoslaw Zarzynski, what do you think?

Actions #11

Updated by Upkeep Bot 8 months ago

  • Merge Commit set to 25fb8aa6716aada36327c75b2648a48408b7a14d
  • Fixed In set to v19.3.0-3579-g25fb8aa6716
  • Upkeep Timestamp set to 2025-07-11T17:40:16+00:00
Actions #12

Updated by Upkeep Bot 8 months ago

  • Fixed In changed from v19.3.0-3579-g25fb8aa6716 to v19.3.0-3579-g25fb8aa671
  • Upkeep Timestamp changed from 2025-07-11T17:40:16+00:00 to 2025-07-14T23:39:46+00:00
Actions #13

Updated by Upkeep Bot 5 months ago

  • Released In set to v20.2.0~2449
  • Upkeep Timestamp changed from 2025-07-14T23:39:46+00:00 to 2025-11-01T01:34:17+00:00
Actions

Also available in: Atom PDF