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 <[email protected]>:
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 <[email protected]
:
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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
