Ceph Storage Capacity Calculator

{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

Host layout:

Choose the way raw host capacity is entered; the calculation still normalizes every value into decimal TB.

Storage hosts:

Enter 1–64 hosts. Protection spread can require more hosts than capacity alone suggests.

Raw capacity per host:

Changing the unit converts the displayed quantity instead of reinterpreting the same digits.

Raw capacity by host:

Every listed host needs a positive capacity. Values share the selected unit.

Capacity unit

Host {{ index }}

Protection preset:

Capacity and spread update together when the protection profile changes.

Protection details:

size

min_size

Failure domain:

Match the selected pool's intended CRUSH failure-domain type.

Domains to tolerate:

Use 1 for a one-domain recovery plan; zero gives a healthy-state estimate without failure reserve.

Custom domain capacity:

The result reports custom spread as a manual CRUSH verification item.

OSDs per host:

Enter the OSD count contributed by each host in the modeled device class.

Target PG replicas per OSD:

Use the cluster's configured target; 100 is the conservative example default.

Similar data pools:

Use one for a single modeled data pool; metadata and differently sized pools need separate planning.

Requested nearfull ratio:

This is a planning boundary, not a recommended steady-state utilization target.

Backfillfull ratio:

Keep this above nearfull and below full.

Full ratio:

The model requires nearfull < backfillfull < full.

OSD and metadata overhead:

Zero is neutral; enter only an allowance supported by the estate being planned.

CRUSH imbalance allowance:

Zero is neutral; use live utilization and weight evidence for a nonzero allowance.

Keep requested nearfull in degraded what-if:

Off is the recovery-safe default.

Measure	Value	Planning meaning	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

Check	Status	Evidence	Next action	Copy
{{ row.label }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}

Profile	Usable	Efficiency	Healthy loss tolerance	Minimum spread	Fit	Copy
{{ row.label }}	{{ row.usable }}	{{ row.efficiency }}	{{ row.tolerance }}	{{ row.spread }}	{{ row.fit }}

Raw disk capacity is only the starting point for a Ceph storage plan. Space is consumed by replication or erasure-code chunks, and more room may need to remain unused so recovery can place data after an object storage daemon (OSD) or host fails. A pool can therefore run out of safe placement room well before the sum of its drives appears full.

Protection changes both usable capacity and failure behavior. A replicated pool stores complete copies. With size=3, one unit of logical data consumes roughly three units of raw placement before other allowances. An erasure-coded pool divides data into k data chunks and adds m coding chunks, giving a raw-to-logical efficiency of k divided by k+m. Erasure coding often saves capacity, but it needs enough distinct placement targets and may not suit every workload or pool role.

Failure domain is the boundary Ceph uses to separate copies or chunks, such as an OSD or host.
Recovery reserve is raw capacity held back so data can be rebuilt after the selected number of domain losses.
Nearfull is an early capacity warning. Backfillfull can stop rebalancing into an OSD, and full can block writes.
Placement groups (PGs) group objects for placement and recovery. Their count affects distribution and operating overhead, not logical capacity alone.

Failure tolerance and write availability are related but different. Replication size or erasure-code m indicates how many losses can be survived without data loss under the modeled placement, while min_size determines how far a pool may degrade before writes stop. Reducing min_size can allow writes with less redundancy, so it should not be treated as extra healthy capacity.

Uneven devices also matter. A cluster with one larger host and several smaller hosts cannot always use every raw terabyte evenly because CRUSH placement and the fullest OSD constrain where new data can go. Capacity planning should therefore compare the arithmetic estimate with the live CRUSH map, device classes, OSD utilization, pool properties, PG autoscaler, and actual recovery behavior.

This model is a design and review aid. It does not query a cluster, simulate CRUSH, account for every BlueStore or metadata cost, or guarantee performance and durability. A configuration should be tested against the intended Ceph release and workload before it is applied.

How to Use This Tool:

Model the raw estate first, then apply the pool's protection, failure-domain reserve, and fullness policy.

Choose Uniform hosts when every storage host contributes the same capacity, or Heterogeneous hosts to enter one positive capacity for each host. Keep the selected TB, TiB, PB, or PiB unit consistent.
Select a protection preset or enter the exact replicated size and min_size, or erasure-code k, m, and min_size used by the planned pool.
Choose the CRUSH Failure domain and how many domains the design should tolerate. Host reserve uses the largest entered hosts first; OSD reserve uses average OSD capacity; custom reserve needs a separately verified domain count and capacity.
Enter OSDs per host and the target PG replicas per OSD. In Advanced settings, match pool count, nearfull, backfillfull, full, overhead, and skew assumptions to the design under review.
Read Capacity ledger for recovery-safe usable space, then review Recovery brief for spread and tolerance failures. Treat Protection scheme matrix as a comparison under the same raw and reserve assumptions, not as an automatic pool recommendation.

Interpreting Results:

Usable capacity is the protected logical capacity available at the effective nearfull ratio after overhead, skew, and recovery reserve are considered. It is intentionally more conservative than raw disk total.

If the configured nearfull ratio leaves too little recovery room, the effective ratio is lowered. Extra raw shows how much additional raw capacity would be needed to retain the configured ratio under the entered reserve assumptions.
A failed spread check means there are fewer known OSD or host placement domains than the selected protection scheme needs. More raw space on too few domains does not fix that.
A failed failure target check means the requested domain losses exceed the healthy tolerance implied by replica count or erasure-code parity chunks.
The PG value is a planning hint. Verify the live autoscaler recommendation and the sum of PG replicas across all pools before changing pg_num.
Enabling the degraded what-if keeps the configured nearfull ratio even when it no longer preserves the modeled recovery reserve. That scenario exposes capacity pressure; it is not a safe default.

Technical Details:

All capacity is normalized to decimal terabytes. One TiB becomes 1.099511627776 TB, one PB becomes 1,000 TB, and one PiB becomes 1,125.899906842624 TB. For heterogeneous hosts, raw capacity is the sum of the individual entries.

Formula Core:

Overhead and skew reduce raw capacity before fullness or protection is applied.

\begin{array}{lll} R_{effective} & = & R_{raw} (1 - o) (1 - s) \\ E_{replicated} & = & \frac{1}{n} \\ E_{EC} & = & \frac{k}{k + m} \\ U_{logical} & = & R_{effective} q_{effective} E \end{array}

o is the entered overhead ratio, s is the skew allowance, n is replica size, and E is the selected protection efficiency. The nearfull ratio is constrained by recovery reserve unless the degraded what-if is enabled.

\begin{array}{lll} q_{reserve} & = & max (0, min (1, 1 - \frac{R_{reserve}}{R_{effective}})) \\ q_{effective} & = & min (q_{configured}, q_{reserve}) \end{array}

Reserve and Tolerance Rules:

Ceph recovery reserve and tolerance rules
Item	Replicated pool	Erasure-coded pool
Protection efficiency	1 / `size`	`k` / (`k` + `m`)
Healthy loss tolerance	`size` − 1	`m`
Losses before modeled write minimum	`size` − `min_size`	`k` + `m` − `min_size`
Minimum known spread	`size` domains	`k` + `m` domains
Host reserve	Sum of the largest entered host capacities up to the failure target
OSD reserve	Failure target × average raw capacity per OSD
Custom reserve	Failure target × entered custom-domain capacity; spread remains a manual check

The model requires nearfull < backfillfull < full. Nearfull may be entered from 0.50 through 0.95, backfillfull from 0.55 through 0.99, and full from 0.60 through 1.00. These are planning inputs; the current OSD map remains authoritative.

PG Hint:

The suggested PG count is the nearest power of two, bounded from 8 through 32,768. The shard factor is replica size for replicated pools and k for erasure-coded pools.

{PG}_{hint} = 2^{round (\log_{2} x)}

Here x equals OSD count multiplied by target PG replicas per OSD, divided by pool count and the selected shard factor. Ceph's autoscaler, pool target-size hints, actual data distribution, and the total PG burden across the cluster can produce a different operational choice.

Accuracy Notes:

Capacity arithmetic cannot reproduce CRUSH placement or the fullest-OSD constraint. Verify the estimate against live cluster state before provisioning or changing a pool.

Overhead and skew are user-entered allowances. They do not measure BlueStore metadata, RocksDB/WAL devices, compression, small-object effects, or device-class imbalance.
Host reserve is conservative for heterogeneous layouts because it removes the largest hosts first. OSD reserve assumes equal average capacity.
Custom failure-domain reserve does not prove that enough distinct CRUSH domains exist.
Erasure-code capacity does not establish workload compatibility, recovery speed, latency, CPU cost, or correct metadata-pool design.
Nearfull, backfillfull, full, pool properties, and PG guidance can change by Ceph release and cluster policy. Inspect the target cluster and release documentation.

Worked Examples:

Six hosts with three replicas

Six 10 TB hosts provide 60 TB raw. Reserving one host leaves a recovery-safe nearfull ratio of 1 − 10/60, or about 83.33%, below a configured 85%. With no extra overhead or skew, 50 TB of raw allocation remains at that ratio; three-way replication yields about 16.67 TB usable. Roughly 6.67 TB more raw would be needed to keep the 85% request while preserving the same 10 TB reserve.

Comparing EC 4+2 on the same estate

Keeping the same 50 TB effective allocation but selecting EC 4+2 changes protection efficiency to 4/6, producing about 33.33 TB usable. The profile needs six placement domains and has two coding chunks, so the capacity gain is meaningful only when the live CRUSH rule can place all six chunks correctly and the intended workload supports the pool design.

References:

Pools, Ceph Documentation.
Erasure Code, Ceph Documentation.
Placement Groups, Ceph Documentation.
Health Checks, Ceph Documentation.
How to create an erasure-coded pool in Ceph, Simplified Guide.
How to troubleshoot full Ceph OSDs, Simplified Guide.