active+undersized — the acting set is short

Intermediate⏱ ~15 mincephcrushtool

What you'll learn

Explain what undersized means at the acting-set level
Distinguish failure-caused from constraint-caused undersizing
Diagnose an unsatisfiable placement constraint
Choose between waiting and changing the constraint

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

Undersized has two entirely different causes with the same symptom, and treating a placement constraint as a failure wastes hours.

What it means

The acting set contains fewer than size OSDs.

# PGID: an undersized PG id from the dump_stuck output below
PGID=7.3d

ceph pg dump_stuck undersized
ceph pg map "$PGID"
# up [12,47] acting [12,47]     ← two entries for a size 3 pool
ceph pg "$PGID" query | jq '.up, .acting'

Clients are served if the remaining count is at least min_size.

The two causes

Failure. An OSD is down or out, and CRUSH has fewer candidates. This is transient and clears when the OSD returns or recovery completes onto a replacement.

Constraint. CRUSH cannot satisfy the rule with the topology available — too few failure domains, too few hosts with the required device class, or OSDs marked out reducing the domain count. This does not clear on its own.

The two-command test

ceph osd tree | grep -c 'up.*1\.00000'    # OSDs up and fully in
ceph osd tree | awk '$NF=="0" {print}'      # OSDs marked out

Then count what the rule needs:

POOL=rbd-vms
RULE=replicated_rule
ceph osd pool get ${POOL} crush_rule
ceph osd crush rule dump ${RULE}
ceph osd tree | grep -c '^-.*rack'          # for a rack rule

If the count of usable domains is below size, this is a constraint and no amount of waiting will fix it. If hardware is genuinely down and enough domains remain, it is a failure and recovery will resolve it.

The whole distinction takes under a minute and determines whether the response is patience or a change.

Diagnosing a constraint

# RULE_ID: the numeric CRUSH rule id shown by ceph osd crush rule dump
RULE_ID=1

# for a device-class rule: how many hosts have that class?
for o in $(ceph osd crush class ls-osd nvme); do
  ceph osd find $o -f json | jq -r '.crush_location.host'
done | sort -u | wc -l

# simulate against the live map
ceph osd getcrushmap -o /tmp/cm.bin
crushtool -i /tmp/cm.bin --test --rule "$RULE_ID" --num-rep 3 --show-bad-mappings

--show-bad-mappings reports exactly which PGs cannot be fully mapped, which is the confirmation.

The responses

For a failure: wait. Recovery restores the acting set.

For a constraint: choose between

adding a failure domain — a host, a rack, or devices of the required class in another host,
lowering the failure domain in the rule — faster, reduces protection,
reducing size — preserves the domain, reduces redundancy.

The first delivers the protection intended. The others are trades that should be recorded.

Why maintenance is the most common cause of constraint undersizing

A cluster designed with exactly size failure domains works perfectly until one is taken out.

Draining a host on a three-host cluster with a host rule, or a rack on a three-rack cluster with a rack rule, leaves the rule unsatisfiable for every PG in the pool. The cluster goes wholly undersized for the duration of the maintenance.

It still serves, because min_size 2 is satisfied. But redundancy is reduced across the entire pool simultaneously, which is a materially different risk posture from a single OSD failure.

# before draining a domain
ceph osd tree | grep -c rack
ceph osd pool ls detail | grep -oP 'size \K[0-9]+'

This is the strongest argument for size + 1 failure domains: not for extra capacity, but so that maintenance on one domain leaves the pool fully redundant rather than universally degraded.

Verifying resolution

PGID=12.1a
ceph pg stat
ceph pg dump_stuck undersized      # should return nothing
ceph pg map ${PGID}                 # up and acting both size entries

Quiz

Knowledge check · 4 questions

Q1. A pool reports every PG undersized with all OSDs up and in. What does this indicate?

A placement constraint — the rule needs more failure domains than exist A failure that recovery has not yet detected, so the acting sets are still short Peering that has not completed, so the acting sets are still being established An imbalance in PG distribution that the balancer will correct on its next pass
Q2. Draining one host on a three-host cluster with a host failure domain leaves the entire pool undersized.

True False
Q3. A pool shows 40% of PGs undersized. All OSDs are up and in, and the failure domain has more buckets than size. Diagnose.

Cluster of 20 hosts across 5 racks. Pool size 3 with a rack-level rule, so 5 racks against a requirement of 3. All 96 OSDs are up and in. Roughly 40% of the pool PGs are undersized, not all. Two racks contain 8 hosts each and three racks contain one host each with 2 OSDs.
Q4. Give the two-command test that distinguishes failure-caused from constraint-caused undersizing.

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

Production discipline

Run the two-command test before doing anything: OSDs down or out, then usable domains against size. A constraint needs a change and a failure needs patience, and treating one as the other wastes hours. Read partial undersizing as a marginal topology — usually badly skewed domain weights — rather than an unsatisfiable rule, and confirm with crushtool --test --show-bad-mappings. And plan for size + 1 domains, since maintenance on a minimal topology undersizes everything at once.

Cross-course references

Ceph: Part XIV (CRUSH Failure Domains) for domain counting.
Ceph: Part XVI (Device Classes) for the class-rule variant.
Ceph: Part XCVI (Node Maintenance) for maintenance planning.