active+clean — what the steady state actually guarantees

Foundation⏱ ~14 minceph

What you'll learn

State precisely what active+clean guarantees
Identify what it does not guarantee
Verify a cluster is fully clean
Recognise conditions that are invisible in a clean cluster

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

active+clean is the goal state after every operation, and knowing exactly what it certifies prevents both false confidence and unnecessary worry.

What it guarantees

active — the PG has completed peering and can serve reads and writes. The acting set has agreed on authoritative history.

clean — the acting set contains size OSDs, the up set matches the acting set, and every OSD holds every object the PG log says it should.

ceph pg stat
# 4096 pgs: 4096 active+clean
ceph -s

Together they mean: full redundancy, no pending movement, no missing objects, and clients served.

What it does not guarantee

That the data is correct. Clean means the replicas agree on which objects exist and their versions, not that their contents match. Only deep scrub verifies contents.
That performance is acceptable. A clean cluster with one saturated OSD serves every request slowly.
That the topology provides the protection intended. A clean size 3 pool whose three copies share a rack is clean.
That capacity is healthy. A cluster at 92% full is clean until it stops.

A clean cluster still needs four checks

ceph pg stat                    # 1. all active+clean
ceph osd perf | sort -k3 -n | tail -5   # 2. latency outliers
ceph df                         # 3. capacity per pool and per class
ceph pg dump | awk '$0 ~ /active\+clean/ {print $(NF-8)}' | sort | head -1
                                # 4. oldest deep scrub

Health being OK covers the first. The other three are the conditions that produce incidents from a cluster reporting no problems: a slow OSD degrading p99, a tier filling, and scrubs falling behind so silent corruption goes undetected.

Verifying full cleanliness

ceph pg stat
ceph pg dump_stuck
ceph health detail

ceph pg stat reporting a single state line with the full PG count is the strongest single confirmation. Any second state line means something is in progress.

Why active+clean does not mean scrubbed recently

A PG becomes clean when its replicas agree on the object list and versions from the PG log. That comparison is metadata only.

Deep scrub reads the actual object data on every replica and compares checksums. A PG can be clean for months while holding a replica with silently corrupted contents, because nothing has read that object and nothing has deep scrubbed it.

ceph pg dump | awk 'NR>1 {print $1, $(NF-8), $(NF-7)}' | head
ceph config get osd osd_deep_scrub_interval
ceph health detail | grep -i scrub

PG_NOT_DEEP_SCRUBBED fires when PGs exceed the interval, and it is a warning worth treating seriously rather than muting — it is the signal that the mechanism protecting cold data has fallen behind.

The relationship worth holding onto: clean is about agreement, scrubbed is about verification, and only the second catches corruption in data nobody reads.

Using it as a gate

active+clean is the correct precondition for elective work:

[ "$(ceph pg stat -f json | jq -r '.pg_summary.num_pg_by_state | length')" -eq 1 ] || {
  echo "cluster not fully clean; refusing"; exit 1
}

Waiting for it between OSD removals, between weight changes, and before starting maintenance is what keeps operations from compounding.

Quiz

Knowledge check · 4 questions

Q1. What does active+clean guarantee about the contents of a placement group replicas?

That every replica matches byte for byte, since the primary verifies checksums as the PG goes clean That the PG was deep scrubbed within the configured interval, since an overdue PG cannot be clean That the replicas agree on which objects exist and their versions, not that contents match That no replica has reported a read error, since a read error would drop the PG out of clean
Q2. A cluster reporting all PGs active+clean and HEALTH_OK needs no further routine checks.

True False
Q3. A cluster reports HEALTH_OK with all PGs active+clean, yet users report intermittent slow VM disk I/O. Investigate.

96-OSD cluster serving RBD to 200 VMs. ceph -s shows HEALTH_OK and 4096 pgs active+clean. Users on roughly a dozen VMs report periodic multi-second I/O stalls; the rest are unaffected. No recent changes. No warnings in the health history.
Q4. State what active and clean each certify, and name three things neither covers.

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

Production discipline

Use active+clean as the gate before elective work, and read a single state line covering the full PG count as the strongest confirmation. But pair it with three checks it does not cover: ceph osd perf outliers for the slow-but-responsive OSD, per-class capacity for a tier filling behind a comfortable cluster average, and the oldest deep scrub timestamp for whether corruption in cold data would be found.

Cross-course references

Ceph: Part LXI (Scrubbing) for the verification half.
Ceph: Part LXVIII (OSD Latency) for finding outliers.
Ceph: Part LXIII (Capacity Management) for the capacity half.