Hi Eugen, thank you for the reply.
The OSD was drained over the weekend, so OSD 223 and 269 have only the
problematic PG 404.bc.
I don't think moving the PG would help since I don't have any empty OSD
to move it to, and a move would not fix the hash mismatch.
The reason I just want to have
Hi,
I'm debating with myself if I should
1. Stop both OSD 223 and 269,
2. Just one of them.
I understand your struggle, I think I would stop them both just to
rule out a replication of corrupted data.
Zitat von Kai Stian Olstad :
Hi Eugen, thank you for the reply.
The OSD was drained
Hi Eugen, thank you for the reply.
The OSD was drained over the weekend, so OSD 223 and 269 have only the
problematic PG 404.bc.
I don't think moving the PG would help since I don't have any empty OSD
to move it to, and a move would not fix the hash mismatch.
The reason I just want to have
Hi,
I think your approach makes sense. But I'm wondering if moving only
the problematic PGs to different OSDs could have an effect as well. I
assume that moving the 2 PGs is much quicker than moving all BUT those
2 PGs. If that doesn't work you could still fall back to draining the
Hi,
No one have any comment at all?
I'm not picky so any speculation, guessing, I would, I wouldn't, should
work and so one would be highly appreciated.
Since 4 out of 6 in EC 4+2 is OK and ceph pg repair doesn't solve it I
think the following might work.
pg 404.bc acting
