> Yeah, there seems to be a fear that attempting to repair those will
> negatively impact performance even more. I disagree and think we should do
> them immediately.
There shouldn’t really be too much of a noticeable performance hit.
Some good documentation here
On 2/28/23 13:11, Dave Ingram wrote:
On Tue, Feb 28, 2023 at 12:56 PM Reed Dier wrote:
I think a few other things that could help would be `ceph osd df tree`
which will show the hierarchy across different crush domains.
Good idea: https://pastebin.com/y07TKt52
Yeah, it looks like
On Tue, Feb 28, 2023 at 12:56 PM Reed Dier wrote:
> I think a few other things that could help would be `ceph osd df tree`
> which will show the hierarchy across different crush domains.
>
Good idea: https://pastebin.com/y07TKt52
> And if you’re doing something like erasure coded pools, or
When I suggested this to the senior admin here I was told that was a bad
idea because it would negatively impact performance.
Is that true? I thought all that would do was accept the information from
the other 2 OSDs and the one with the errors would rebuild the record.
The underlying disks
I think a few other things that could help would be `ceph osd df tree` which
will show the hierarchy across different crush domains.
And if you’re doing something like erasure coded pools, or something other than
replication 3, maybe `ceph osd crush rule dump` may provide some further
context
Den tis 28 feb. 2023 kl 18:13 skrev Dave Ingram :
> There are also several
> scrub errors. In short, it's a complete wreck.
>
> health: HEALTH_ERR
> 3 scrub errors
> Possible data damage: 3 pgs inconsistent
> [root@ceph-admin davei]# ceph health detail
> HEALTH_ERR 3
