Choosing among the common profiles

Why this matters in production

The profile is fixed for the life of the pool. Changing it means creating a new pool and moving every object — a project, not a change. The decision deserves a structured comparison rather than a default.

The four axes

“Serving through” is m − 1 domain losses, because min_size is k+1. That column is usually the one the requirement is actually about.

Reading the table

4+2 — the sensible default for a mid-sized cluster. Six domains is achievable, 1.5× is a large saving over replication, recovery reads are tolerable.

6+3 — same capacity as 4+2 with an extra chunk of durability. If you have nine failure domains, it is generally the better choice.

8+3 — better capacity than either, needs eleven domains, and recovery touches eight OSDs per rebuild. Good for large archives on wide clusters.

10+4 — for large clusters that need to survive three domain losses while serving. Fourteen domains minimum, and recovery is expensive enough that the cluster network becomes the binding constraint.

Very wide (17+3 and beyond) — capacity-optimal, and only sensible on clusters with many dozens of hosts, a fast network, and cold data. The recovery and degraded-read costs are severe.

The rules that decide it

1. Domains available. You need k+m, and you want meaningful headroom above it. This eliminates most profiles on most clusters immediately.
2. Required availability during failures. Convert the requirement to m − 1 domain losses. If the answer is “two,” you need m ≥ 3.
3. Object size. Objects must be substantially larger than k × min_alloc_size or the capacity advantage evaporates.
4. Network headroom. Recovery moves k× the rebuilt volume. Check the cluster network against the largest OSD you deploy.

When EC is the wrong answer

• Small objects — the allocation overhead cancels the saving
• Small random writes — every partial write becomes read-modify-write
• Latency-sensitive workloads — k OSDs must respond, not one
• Clusters with fewer than about six failure domains — no profile fits with headroom

ceph osd erasure-code-profile ls
ceph osd erasure-code-profile get default

Quiz

Production discipline

Put the profile decision through a written comparison of the four axes and keep it with the cluster design, because the reasoning is what a future operator needs when asked whether the profile is still appropriate. Re-examine it whenever the cluster’s domain count or network changes materially — the profile cannot change, but knowing it has become marginal is worth planning around.

Cross-course references

• Kubernetes: choosing a replica count and topology spread is the same fixed-at-design decision
• Linux: RAID level selection carries the same one-way-door property once an array is populated