Actions
Bug #41748
closedlog [ERR] : 7.19 caller_ops.size 62 > log size 61
% 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
2019-09-10T10:35:14.569+0000 7fafed2fb700 10 osd.3 pg_epoch: 687 pg[7.19( v 684'2861 (681'2800,684'2861] local-lis/les=686/687 n=1786 ec=600/595 lis/c=679/663 les/c/f=680/664/0 sis=686) [3,6,1] r=0 lpr=686 pi=[663,686)/1 crt=684'2861 lcod 684'2860 mlcod 0'0 unknown mbc={}] activate - no missing, moving last_complete 684'2861 -> 684'2861
2019-09-10T10:35:14.569+0000 7fafed2fb700 -1 log_channel(cluster) log [ERR] : 7.19 caller_ops.size 62 > log size 61
/a/sage-2019-09-09_21:49:42-rados-wip-sage3-testing-2019-09-09-1123-distro-basic-smithi/4293546
This comes from log_weirdness(), which (at the time) was only called on pg load and in activate, so it's not immediately clear when the inconsistency appeared.
Updated by Sridhar Seshasayee over 4 years ago
- Assignee set to Sridhar Seshasayee
Updated by Sage Weil over 4 years ago
I suggest putting a call to log_weirdness() in the Reset state entry point, so we can tell if the problem came from the prior interval. And then put it in the various peering stages (GetInfo, GetLog, GetMissing) so we can tell if it came from one of those.
Updated by Sridhar Seshasayee over 4 years ago
Sage, the calls to log_weirdness() in the places you suggested are already in place. They were added by you as part of 60aef55d43c5bd9d4095dbc76314be3c67d73878.
Updated by Neha Ojha over 3 years ago
- Status changed from Need More Info to Can't reproduce
Actions