You have only 8 PGs in total? They take up several hundreds of GB, making one PG quite large. That's why it's backfill_toofull, it can't store another 200 GB (or so) on that OSD because it would breach the (default) limit of 90%. You need to increase pg_num drastically to decrease your PG sizes. As a first shot I would aim for 100 PGs per OSD or so. Zitat von Sinan Polat via ceph-users <ceph-users@ceph.io>:

Hi,

The cluster-wide utilization isn't the important metric here. backfill_toofull means that the destination OSD selected for the backfill is above the configured backfillfull_ratio, regardless of how much free space the cluster has overall.

Can you post the output of: ceph pg 7.0 query ceph osd dump | egrep 'nearfull_ratio|backfillfull_ratio|full_ratio'

Kind regards, Sinan

Op za 11 jul 2026 om 09:41 schreef listy via ceph-users <ceph-users@ceph.io

...

:

...

Hi guys.

Is what ceph claims really the case?

CEPH status is: HEALTH_WARN Low space hindering backfill (add storage if this doesn't resolve itself): 1 pg backfill_toofull; Degraded data redundancy: 69353/208545 objects degraded (33.256%), 1 pg degraded, 1 pg undersized [WRN] PG_BACKFILL_FULL: Low space hindering backfill (add storage if this doesn't resolve itself): 1 pg backfill_toofull pg 7.0 is active+undersized+degraded+remapped+backfill_toofull, acting [3,2] [WRN] PG_DEGRADED: Degraded data redundancy: 69353/208545 objects degraded (33.256%), 1 pg degraded, 1 pg undersized pg 7.0 is stuck undersized for 7m, current state active+undersized+degraded+remapped+backfill_toofull, last acting [3,2]

-> $ ceph osd df tree ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 1.61128 - 1.6 TiB 816 GiB 814 GiB 369 KiB 1.6 GiB 834 GiB 49.48 1.00 - root default -3 0.53709 - 550 GiB 272 GiB 271 GiB 147 KiB 540 MiB 278 GiB 49.44 1.00 - host podster1 2 MONERO 0.39059 1.00000 400 GiB 272 GiB 271 GiB 96 KiB 499 MiB 128 GiB 67.96 1.37 3 up osd.2 5 MONERO 0.14650 1.00000 150 GiB 49 MiB 8.1 MiB 51 KiB 41 MiB 150 GiB 0.03 0 0 up osd.5 -7 0.53709 - 550 GiB 272 GiB 271 GiB 171 KiB 532 MiB 278 GiB 49.43 1.00 - host podster2 0 MONERO 0.14650 1.00000 150 GiB 60 MiB 8.5 MiB 92 KiB 51 MiB 150 GiB 0.04 0 1 up osd.0 3 MONERO 0.39059 1.00000 400 GiB 272 GiB 271 GiB 79 KiB 481 MiB 128 GiB 67.96 1.37 2 up osd.3 -5 0.53709 - 550 GiB 273 GiB 271 GiB 51 KiB 543 MiB 277 GiB 49.58 1.00 - host podster3 1 MONERO 0.14650 1.00000 150 GiB 447 MiB 8.5 MiB 16 KiB 38 MiB 150 GiB 0.29 0.01 1 up osd.1 4 MONERO 0.39059 1.00000 400 GiB 272 GiB 271 GiB 35 KiB 504 MiB 128 GiB 68.06 1.38 1 up osd.4 TOTAL 1.6 TiB 816 GiB 814 GiB 372 KiB 1.6 GiB 834 GiB 49.48

MIN/MAX VAR: 0/1.38 STDDEV: 37.28

I cannot "decipher" this - can you help, explain what is (not)happening here - this "state" persists for a few days, I do not suppose it will heal itself.

many thanks, L. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

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