The acting set is the safety boundary

Why this matters in production

Cluster-level health is a summary; the acting set is the truth. Whether a particular client can do its work depends on the acting sets of the PGs its objects live in, and nothing else. Every other diagnostic is a route to that number.

The rule

A PG serves I/O — reads and writes both — when its acting set contains at least min_size OSDs with current data.

That single sentence covers every case:

Reads are not a special case

A common and dangerous misconception is that reads survive below min_size because the data is physically present on the surviving OSD. They do not. A PG below min_size does not go active, and an inactive PG serves nothing at all.

The reason is correctness, not caution. Until peering completes with enough peers, the cluster cannot establish which copy reflects the most recent acknowledged writes. Serving from an unverified copy could return data the client already knows was overwritten. Ceph treats unprovable data as unavailable.

Reading the boundary during an incident

ceph pg map 7.3d
# osdmap e41207 pg 7.3d (7.3d) -> up [12,47,83] acting [12]

acting [12] — one OSD. Against min_size 2, that PG is blocked. This is the single most informative line in a Ceph incident, and it takes one command.

At scale:

ceph pg dump_stuck inactive --format json | \
  jq -r '.[] | "\(.pgid) acting=\(.acting|length)"'

Applying it before the failure

The boundary is predictive, not just diagnostic. Given a proposed maintenance action — draining a host, rebooting a rack — you can determine in advance whether any PG’s acting set will fall below min_size:

# which PGs currently have a replica on the host you plan to take down?
ceph pg ls-by-osd 47

If a PG appears with an already-reduced acting set, taking down another of its members blocks it. That check turns a risky maintenance window into a routine one.

Quiz

Production discipline

Make inactive PG count a distinct alert with a higher severity than degraded PG count — they are different conditions with different urgency and should not share a threshold. Add the pre-maintenance overlap check to your host-reboot runbook; it is the difference between a routine window and an unexpected partial outage.

Cross-course references

• Kubernetes: available replicas in a Deployment status is the same kind of boundary reading
• Linux: checking mdadm array state before pulling a disk is the identical pre-flight discipline