Raising the ratios as a bridge, not a fix

Advanced⏱ ~18 minceph

What you'll learn

State precisely what raising each ratio permits
Identify the OSD-side failsafe that bounds every ratio change
Assess the cluster-wide blast radius of a ratio change
Run a threshold change with a defined revert trigger

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Raising a ratio creates no space. It moves the line at which Ceph stops protecting you, and it does so for every OSD in the cluster at once. It is a legitimate bridge and a catastrophic destination.

What the change actually grants

ceph osd dump | grep -E 'full_ratio|nearfull_ratio'

full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85

Raising	Grants	Costs
`nearfull`	quiet	the warning that would flag the next event
`backfillfull`	permission for backfill and rebalancing to resume	movement into OSDs with less remaining margin
`full`	permission for clients to keep writing	the margin that keeps an OSD restartable

ceph osd set-backfillfull-ratio 0.91
ceph osd set-full-ratio 0.96

The monitors enforce ordering: nearfull below backfillfull below full. A change that inverts them is rejected, which is why the backfillfull raise usually has to come with a full raise behind it.

The ceiling you cannot raise

ceph config get osd osd_failsafe_full_ratio

0.970000

Each OSD refuses writes at its own failsafe regardless of the monitor ratio. Setting full_ratio to 0.98 grants nothing above 0.97 — the OSD stops on its own, from its own view of its own device.

The blast radius is every OSD

ceph osd df | sort -k17 -n | tail -8

The ratios are cluster-wide. There is no per-pool or per-class full
ratio, so raising the line to unblock one pool removes the same margin
from every OSD serving every other pool.

Before the change	After a raise to 0.96
one OSD blocked at 95%	that OSD writable, with 1% of margin left
forty OSDs protected at 95%	forty OSDs now permitted to reach 96%
the incident visible in health	the incident silent until the new line

The bookkeeping

Record	Example
Original values	`full 0.95 backfillfull 0.90 nearfull 0.85`
New values	`full 0.96 backfillfull 0.91`
Reason	unblock backfill onto twelve new OSDs
Revert trigger	fullest OSD below 85%
Owner and deadline	on-call lead, revert within 24 hours

# write the revert before running the raise
cat > /root/incident/revert-ratios.sh <<'EOF'
ceph osd set-full-ratio 0.95
ceph osd set-backfillfull-ratio 0.90
ceph osd set-nearfull-ratio 0.85
EOF
chmod +x /root/incident/revert-ratios.sh

bash /root/incident/revert-ratios.sh
ceph osd dump | grep -E 'full_ratio|nearfull_ratio'

Quiz

Knowledge check · 4 questions

Q1. What does raising `full_ratio` from 0.95 to 0.98 achieve?

Three percent more usable capacity across the cluster, which on a 470 TiB deployment is roughly 14 TiB of extra space Nothing above 0.97, because each OSD refuses writes at its own `osd_failsafe_full_ratio` regardless of the monitor ratio A per-pool exemption from the full condition, since `full_ratio` is compared against each pool's usage rather than a device It re-enables backfill without touching `backfillfull`, because the monitors derive the lower ratio from the higher one
Q2. The last few percent the full ratio protects exists to keep the OSD operable, not to reserve space for data.

True False
Q3. Decide whether to raise the ratios during an incident.

Twelve new OSDs are deployed and empty because the cluster is above backfillfull. The fullest existing OSD is at 91%. Deletion has freed nothing so far and the inflow is stopped.
Q4. Why is raising a ratio to unblock one pool a cluster-wide decision?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Write the revert script before running the raise and state the revert trigger as a measured condition, not as a time of day. Never raise a ratio while the inflow is still running — the margin is consumed and you arrive at the same crisis with less protection — and never raise full_ratio toward osd_failsafe_full_ratio, because an OSD that fills completely stops being a capacity problem and becomes a repair.

Cross-course references

Kubernetes: raising a resource quota to unblock a deploy removes the limit that would catch the next one
Linux: tune2fs reserved blocks exist to keep the filesystem repairable, not to store data