Actions
Bug #37511
closedmerge target placeholder may get wrong PastIntervals from source
% Done:
0%
Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
2018-12-03 19:31:43.683 7f3f98761700 10 osd.5 pg_epoch: 1214 pg[2.ds2( DNE v 829'280 lc 0'0 (0'0,829'280] local-lis/les=0/0 n=0 ec=0/0 lis/c 0/0 les/c/f 0/0/0 0/0/0) [1,4,3]p1(0) r=-1 lpr=1214 (info mismatch, log((0'0,0'0], crt=0'0)) crt=0'0 unknown mbc={}] merge_from taking source's past_intervals
2018-12-03 19:31:43.683 7f3f98761700 10 osd.5 pg_epoch: 1214 pg[2.ds2( v 829'280 (829'280,829'280] lb MIN (NIBBLEWISE) local-lis/les=0/1039 n=0 ec=995/19 lis/c 1094/1094 les/c/f 1039/1039/0 1036/1213/1213) [1,4,3]p1(0) r=-1 lpr=1214 pi=[1094,1213)/1 crt=829'280 lcod 0'0 unknown mbc={}] merge_from set les/c to 1039/1039 from pool last_dec_*, source pg history was ec=995/19 lis/c 1094/1094 les/c/f 1095/1212/0 1036/1213/1213
note last_epoch_clean is 1039, but pi=[1094,1213)/1.
//a/sage-2018-12-03_17:39:26-rados-wip-sage2-testing-2018-12-03-0942-distro-basic-smithi/3304273
presumably this is because the source pg was able to do more peering than the target (moving forward to 1094)?
Updated by Sage Weil over 5 years ago
- Assignee set to Sage Weil
- Priority changed from High to Urgent
I think the fix is to just bite the bullet and put PastIntervals at decrement time in the pg_info_t, along with the other dec_* fields.
Updated by Sage Weil over 5 years ago
/a/sage-2018-12-17_17:34:16-rados-wip-sage2-testing-2018-12-17-0911-distro-basic-smithi/3372061
Updated by Sage Weil over 5 years ago
- Status changed from 12 to Fix Under Review
Updated by Sage Weil over 5 years ago
- Status changed from Fix Under Review to Resolved
Actions