Bug #37509: require past_interval bounds mismatch due to osd oldest_map - RADOS - Ceph

Actions

Copy link

Bug #37509

closed

require past_interval bounds mismatch due to osd oldest_map

Added by Sage Weil over 5 years ago. Updated almost 4 years ago.

Status:

Can't reproduce

Priority:

High

Assignee:

Category:

Target version:

% Done:

Source:

Tags:

Backport:

nautilus

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Component(RADOS):

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

2018-12-03 18:58:37.688 7f93af6a9700 10 osd.1 pg_epoch: 704 pg[1.30( empty local-lis/les=496/497 n=0 ec=496/15 lis/c 496/496 les/c/f 497/497/0 498/498/486) [7,6] r=-1 lpr=704 pi=[496,498)/1 crt=0'0 unknown NOTIFY mbc={}] check_recovery_sources no source osds () went down
2018-12-03 18:58:37.688 7f93af6a9700 -1 log_channel(cluster) log [ERR] : 1.30 required past_interval bounds are empty [515,498) but past_intervals is not: ([496,497] intervals=([496,497] acting 1,7))

note from first line that last_epoch_clean is 497, same_interval_since is 498, and pi is ([496,497] intervals=([496,497] acting 1,7)), which is all fine.

the required bound looks like [515,498) because superblock.oldest_map is 515.

//a/sage-2018-12-03_17:39:26-rados-wip-sage2-testing-2018-12-03-0942-distro-basic-smithi/3304196

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Sage Weil over 5 years ago

I don't think the superblock.oldest_map should be a factor in this calculation. I suspect it is in there to deal with skipped maps, but in those situations I think we should use a different strategy (e.g., not munge required intervals at this level) to proceed... by, say, not checking interval bounds at all. or something.

Actions

Copy link