target_size_bytes and target_size_ratio

Why this matters in production

The autoscaler’s weakness is that it can only see the present. You know things it does not: that this pool is the landing zone for a 40 TB migration next quarter, that this one will never exceed 2 TB. Target size is the interface for handing over that knowledge, and it converts the autoscaler from a reactive tool into a planning one.

The two forms

target_size_bytes — an absolute figure. “This pool will hold 40 TB of user data.”

ceph osd pool set migration-landing target_size_bytes 40T

target_size_ratio — a proportion of the cluster. “This pool will occupy 30% of raw capacity.”

ceph osd pool set migration-landing target_size_ratio 0.30

Either one replaces SIZE as the module’s input, so the recommendation reflects the destination rather than the starting point. The pool gets its final PG count immediately, and the data grows into it — no splits along the way, no repeated rebalances.

Which one to use

The ratio form is the more durable of the two on a cluster you expect to expand: add OSDs and a pool declared at 0.30 still gets 30% of the PG budget, whereas a pool declared at 40 TB becomes a progressively smaller fraction and its PG count drifts down relative to the whole.

Set only one. If both are set, target_size_ratio wins and Ceph raises a health warning telling you so.

Over-commitment

POOL_TARGET_SIZE_RATIO_OVERCOMMITTED

Targets are claims on capacity, and the module adds them up. Declare 0.4, 0.4, and 0.5 across three pools and you have promised 130% of the cluster. The module scales the claims back proportionally so the PG budget still adds up, and warns you — because if all three pools actually reach their declared size, you run out of disk.

ceph osd pool set pool-a target_size_ratio 0.30
ceph osd pool set pool-b target_size_ratio 0.30
ceph osd pool set pool-c target_size_ratio 0.20
# total 0.80 — leaves headroom, no warning

Quiz

Production discipline

Treat target size as documentation with teeth: it should match a capacity plan somebody wrote down, not a guess typed at a prompt. Review targets whenever the cluster grows, and clear the ones tied to finished migrations. A quarterly walk through autoscale-status comparing declared targets against actual growth catches both stale claims and pools quietly outgrowing their plan.

Cross-course references

• Kubernetes: a namespace ResourceQuota is the same idea — a declared future claim that shapes present scheduling
• Linux: think of it as thin-provisioning a filesystem, with the same over-commitment discipline