Bug #1340
closedOSD: Strange scrub behavior
0%
Files
Updated by Fyodor Ustinov over 12 years ago
- File osd.5.log.5.gz osd.5.log.5.gz added
- File osd.5.log.6.gz osd.5.log.6.gz added
- File osd.5.log.7.gz osd.5.log.7.gz added
- File osd.5.log osd.5.log added
- File osd.5.log.1.gz osd.5.log.1.gz added
- File osd.5.log.2.gz osd.5.log.2.gz added
- File osd.5.log.3.gz osd.5.log.3.gz added
- File osd.5.log.4.gz osd.5.log.4.gz added
OSD5 logs.
Updated by Greg Farnum over 12 years ago
Okay, this is just bizarre. There are actually 4 different PGs that report a stat mismatch error. 3 of them (including 0.f8) are off by the exact same amount -- 34055KB more in the on-disk state than the in-memory info -- and the other two somehow fix themselves. 0.f8 seems to eventually fix itself, since after doing the repair (which detects the same problem as the initial scrub 3.5 hours later, so the problem can't be JUST a race) it later says "hey, my recorded stats are too high compared to my on-disk state!" and then reduces it by the same amount it initially incremented them by.
But, somehow, between the first repair and the next scrub, the on-disk quantity goes down despite the PG adding 8 objects and apparently only doing write operations (since the repgather commit messages are set to way too high a debug level, this is the one thing I can see).
Updated by Greg Farnum over 12 years ago
- Status changed from In Progress to Rejected
Not A Bug!
Fyodor wrote:
"Hmmm" I said to myself.
stop osd5
fsck -fy /dev/sdb1And got:
Inode 230558734, i_blocks is 8, should be 16. Fix? yes
Inode 230559279, i_blocks is 8208, should be 8200. Fix? yes
Inode 230559410, i_blocks is 40, should be 32. Fix? yes
Inode 230559527, i_blocks is 24, should be 32. Fix? yes
Inode 231342174, i_blocks is 40, should be 32. Fix? yes
Inode 231342209, i_blocks is 24, should be 32. Fix? yes