On 2019-11-22 21:45, Paul Emmerich wrote:
On Fri, Nov 22, 2019 at 9:33 PM Zoltan Arnold Nagy <zoltan@linux.vnet.ibm.com> wrote:
The 2^31-1 in there seems to indicate an overflow somewhere - the way we were able to figure out where exactly is to query the PG and compare the "up" and "acting" sets - only _one_ of them had the 2^31-1 number in place of the correct OSD number. We restarted that and the PG started doing its job and recovered.
no, this value is intentional (and shows up as 'None' on higher level tools), it means no mapping could be found
thanks, didn't know.
check your crush map and crush rule
if it were indeed a crush rule or map issue, it would not have been resolved by just restarting the primary OSD of the PG, would it? the crush rule was created by running ceph osd erasure-code-profile set ec42 k=4 m=2 crush-device-class=nvme where the default failure domain is host; as I said we have 12 hosts, so I don't see anything wrong here - it's all default... this is why I suspect a bug, just don't have any evidence other than that it happened to us :)