Ceph Erasure Coding Calculator

How to calculate Ceph erasure coding capacity

Enter the number of OSDs available to the pool and the capacity of each drive. This model assumes equal-sized devices and one OSD per drive. Raw capacity is OSD count multiplied by drive size. The default example, 24 OSDs with 16 TB each, supplies 384 TB before redundancy. Count only the devices the pool's placement rule can select, rather than every disk in a cluster with separate storage tiers.

A replicated pool with size three stores three complete copies, so theoretical usable capacity is raw capacity divided by three. Erasure coding divides an object into k data chunks and adds m coding chunks. Its capacity fraction is k divided by k+m, while its space amplification is the inverse, (k+m) divided by k. These are the formulas in Ceph's erasure coding documentation.

k+m overhead at 384 TB raw

With 4+2, each four chunks of data require two more coding chunks. That means 50% extra raw space relative to user data, or one third of the raw space used for coding. Thus 384 multiplied by 4/6 yields 256 TB. The 8+4 profile has the same ratio, so its output is also 256 TB; increasing both numbers proportionally does not increase capacity efficiency. These are arithmetic examples, not measured storage results.

Host count changes the meaning of the result

*The table assumes a host failure domain with one replica or EC chunk per host for each object. Under that rule, 4+2 needs six eligible hosts to place its six chunks, while 8+4 needs twelve. Twenty-four OSDs spread over three hosts do not meet either requirement. The calculator has no topology input, so a positive capacity result does not validate the proposed cluster layout.

Ceph recommends planning additional failure domains for recovery: k+m+1 gives an EC pool somewhere to rebuild after losing one domain, provided sufficient capacity remains. For the assumptions here, that means seven hosts for 4+2 or thirteen for 8+4. Read the pool placement guide before treating a parts list as a deployable topology.

Leave capacity for metadata and recovery

The output uses decimal TB and applies only the redundancy ratio. It does not subtract BlueStore metadata, allocation and EC padding overhead, or an operating reserve. Uneven device utilization and placement constraints also affect how much space a pool can actually accept. Compare the estimate with ceph df detail and ceph osd df on an existing cluster; the OSD_NEARFULL guidance explains why the fullest eligible OSD matters before the raw total is exhausted.

For example, reserving 20% of the theoretical 256 TB leaves 204.8 TB as a planning budget. That percentage is an illustrative choice, not a Ceph guarantee or a built-in calculator deduction. Choose a reserve that also allows the intended recovery after a host failure. If expansion is required, follow the guide to add an OSD to Ceph and check that the new device belongs to a host and media class the affected pool can use.

The memory output is an OSD target total

For the default 24 OSDs, multiplying by the default 4 GiB memory target gives 96 GiB. This is a sum across daemons, not a server RAM recommendation or a hard consumption limit. Apply Ceph's hardware guidance to each host, allowing for its OSD count, other services and recovery load. Changing the redundancy dropdown does not change the displayed memory target, and the tool does not model the additional CPU or I/O work of erasure coding.

Related guides

• Erasure coding versus replication — what each redundancy profile costs in space, durability and write latency.
• Ceph hardware requirements — the published minimums for OSD processors, memory, drives and networking.
• How Ceph places data — why the failure domain in a CRUSH rule decides how many hosts a profile needs.