Besides Michels response regarding the default of 24 hours after which the warning usually would disappear, I wanted to mention that we also saw this warning during some network issues we had. So if the disks seem okay, I'd recommend to check the network components.

Zitat von Jan Kasprzak <k...@fi.muni.cz>:

Hello again,

I still have problem with occasional "slow operations in BlueStore"
warning, which I don't know how to clear/acknowledge except restarting
that OSD process (or doihg "ceph osd down/up" cycle).

When I previously asked about this several weeks ago, the underlying cause
was HDD with SMART errors logged. I replaced that disk eventually, but now I am
occasionally getting the same warning from different OSDs, which do not
have any SMART errors or pending/reallocated sectors.

How can I see whether it was one-time problem and now it is OK, and how can
I clear the warning manually or automatically after some time?

Thanks!

-Yenya

Anthony D'Atri wrote:


>
>    Hello, Ceph users,
>
> TL;DR: how to clear/acknowledge the following warning from ceph -s?
>
>    health: HEALTH_WARN
>            1 OSD(s) experiencing slow operations in BlueStore
>
> Details:
> This is caused by a bad sector on the physical HDD - the time of this
> warning is the same as the most recent error in the SMART log of that HDD.

If this is the case, the drive might warrant replacement.

A few grown defects are not entirely alarming, but if there are more than, say, 10 then I’d replace the drive.

Or if there are SATA downshifts or other errors.


>
> # ceph health detail
> HEALTH_WARN 1 OSD(s) experiencing slow operations in BlueStore
> [WRN] BLUESTORE_SLOW_OP_ALERT: 1 OSD(s) experiencing slow operations in BlueStore
>     osd.33 observed slow operation indications in BlueStore
>
> When I restart osd.33 using "systemctl restart ceph-osd@33.service"
> on the OSD host, the warning disappears. But is there a "softer" way
> how to acknowledge this warning?

        ceph osd down 33

does not touch the process, only the maps and peering, which often suffices.

>
> Thanks!
>
> -Yenya
>
> --
> | Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> | > | https://www.fi.muni.cz/~kas/ GPG: 4096R/A45477D5 |
>    We all agree on the necessity of compromise. We just can't agree on
>    when it's necessary to compromise.                     --Larry Wall
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io

--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| https://www.fi.muni.cz/~kas/                        GPG: 4096R/A45477D5 |
    We all agree on the necessity of compromise. We just can't agree on
    when it's necessary to compromise.                     --Larry Wall
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io


_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to