GlusterFS Volume Capacity Calculator

Projected Usable Capacity

{{ formatCap(rawEffective) }} {{ unit }} Raw (post-overhead) {{ modeLabel }} {{ (100 * efficiency).toFixed(1) }} % Efficiency

Total bricks:

Brick size:

Define each brick manually (heterogeneous):

Per-brick capacities:

Brick {{ i }} {{ unit }}

Filled: {{ manualFilledCount }} / {{ Math.max(0, Math.floor(Number(brickCount) || 0)) }} bricks.

Volume type:

replica

arbiters

data (k)

redundancy (m)

groups

per group

Filesystem/metadata overhead :

{{ (fsOverhead*100).toFixed(1) }} %

Target fill (occupancy) :

{{ (targetFill*100).toFixed(0) }} %

Metric	Value
Bricks	{{ nActive }}
Mode	{{ modeLabel }}
Groups used	{{ groupsUsed }}
Raw storage (all) ({{ unit }})	{{ formatCap(rawAll) }}
Raw active ({{ unit }})	{{ formatCap(rawActive) }}
Equalized raw ({{ unit }})	{{ formatCap(equalizedRaw) }}
Overhead ({{ unit }})	{{ formatCap(equalizedRaw - rawEffective) }}
Raw post-overhead ({{ unit }})	{{ formatCap(rawEffective) }}
Target fill	{{ (targetFill*100).toFixed(0) }} %
Protected efficiency	{{ (efficiency*100).toFixed(2) }} %
Usable capacity ({{ unit }})	{{ formatCap(usable) }}
Redundancy overhead ({{ unit }})	{{ formatCap(redundancyRaw) }}
Reserved / free ({{ unit }})	{{ formatCap(reservedRaw) }}
Fault tolerance	{{ faultToleranceText }}
{{ note }}

Tags: Devops , Storage , Sysadmin

Export to PDF Fullscreen

Embed:

Stacked disks representing storage capacity.

GlusterFS volumes are distributed storage collections of bricks that provide space and resilience across machines. A compact capacity planning calculator helps compare protection choices and headroom so estimates match real clusters.

You enter the number of bricks and their size or list each brick when capacities differ. Then choose distributed replication or erasure coding and set expected file system overhead and your target fill so the result reflects reserved headroom.

The output shows projected usable capacity and the share consumed by redundancy overhead reserved space and file system overhead. A quick example with twelve bricks of ten terabytes and three way replication shows how the result shifts when you lower the fill target.

Treat the figures as planning numbers not guarantees because file layout small files and mixed workloads can move the needle. Use consistent units and keep assumptions the same when comparing options.

Technical Details:

The quantities measured are brick capacities and how they participate in a GlusterFS volume. From those inputs the tool computes raw capacity, applies file system overhead, reserves a target fill, and then applies protection efficiency to estimate usable capacity. Replication and erasure coding change efficiency and fault tolerance at the set level.

Computation proceeds by summing active bricks, subtracting overhead to get effective raw space, multiplying by the chosen fill target, and finally scaling by protection efficiency. Results are partitioned into usable data, redundancy, reserved headroom, and overhead so trade‑offs are visible.

Interpretation focuses on how efficiency varies by mode: distributed has full efficiency; replicated mode yields 1 ⁄ r; replicated with an arbiter yields (r − a) ⁄ r; dispersed erasure coding yields k ⁄ (k + m). Crossing to larger replica widths or higher redundancy m trades space for fault tolerance.

Comparability assumes consistent units and the same brick list. Heterogeneous inputs are handled by using the largest bricks first to fill the active sets; comparisons across different brick mixes may therefore shift slightly with ordering.

\begin{array}{lll} R {raw}_{all} & = & \sum_{i = 1}^{n} C_{i} \\ R {active}_{} & = & \sum_{i = 1}^{n {active}_{}} C_{i} \\ R {eff}_{} & = & R {active}_{} \cdot (1 - f) \\ U {raw}_{} & = & R {eff}_{} \cdot t \\ η & = & dist : 1, rep : \frac{1}{r}, rep_arb : \frac{r - a}{r}, ec : \frac{k}{k + m} \\ U & = & U {raw}_{} \cdot η \end{array}

Symbols and units
Symbol	Meaning	Unit/Datatype	Source
n	Total bricks	integer	Input
Ci	Capacity of brick i	MB \| GB \| TB \| PB \| MiB \| GiB \| TiB \| PiB	Input
r	Replica width	integer	Input
a	Arbiters per set	integer	Input
k, m	EC data and redundancy bricks	integers	Input
nactive	Active bricks used	integer	Derived
f	File system/metadata overhead	fraction	Input
t	Target fill (occupancy)	fraction	Input
η	Protected efficiency	fraction	Derived
U	Usable capacity	same as input unit	Derived

Worked example:

12 bricks × 10 TB, replication r = 3, f = 0.03, t = 0.90.

\begin{matrix} R {active}_{} & = & 120 TB \\ R {eff}_{} & = & 120 \cdot (1 - 0.03) = 116.40 TB \\ U {raw}_{} & = & 116.40 \cdot 0.90 = 104.76 TB \\ η & = & \frac{1}{3} = 0.3333 \\ U & = & 104.76 \cdot 0.3333 \approx 34.92 TB \end{matrix}

Interpretation: about 34.92 TB usable, 69.84 TB redundancy, 11.64 TB reserved, 3.60 TB overhead.

Collect brick capacities; blanks or non‑finite values count as zero.
Determine minimum bricks per group: replica r (≥ 2), arbiter r (≥ 3), or EC k + m.
Compute groups used as the lesser of requested groups and what the bricks can fill.
Sum the largest active bricks to get R_active.
Apply overhead f to get effective raw space.
Apply fill target t to reserve headroom.
Apply efficiency η per mode to estimate usable capacity.

Units, precision, and rounding: Inputs use SI (MB, GB, TB, PB) or IEC (MiB, GiB, TiB, PiB). Numbers are computed in double‑precision floating point and displayed with up to two decimal places using locale‑aware separators.

Validation rules extracted from the UI
Field	Type	Min	Max	Step/Pattern	Error Text	Notes
Total bricks	number	1	—	step 1	—	Sets number of inputs when heterogeneous.
Brick size	number	0	—	step 0.01	—	Capacity per brick before overhead.
Per‑brick capacities	number	0	—	step 0.01	—	Blank counts as zero.
Mode	enum	—	—	dist \| rep \| rep_arb \| ec	—	Volume type.
Replica width	number	2 (rep) / 3 (rep_arb)	—	step 1	—	Bricks per replica set.
Arbiters per set	number	1	r − 1	step 1	—	Used only in replicated with arbiter.
EC data k	number	1	—	step 1	—	Dispersed data bricks.
EC redundancy m	number	1	—	step 1	—	Dispersed redundancy bricks.
Groups	number	1	—	step 1	—	Number of sets to build.
Per group	number	min = max(required, input)	—	step 1	—	Required: r for rep, r for rep_arb, k + m for EC.
File system overhead f	range	0	0.15	step 0.005	—	Clamped to 0 … 0.99 internally.
Target fill t	range	0.50	1.00	step 0.01	—	Reserves headroom below 100 %.
Units	enum	—	—	MB, GB, TB, PB, MiB, GiB, TiB, PiB	—	SI or IEC.

I/O: Inputs are numeric fields (integers for counts, decimals for capacities). Outputs include a tabular breakdown, a donut visualization, and optional CSV/JSON exports. Clipboard and file downloads occur locally.

Privacy & compliance: Processing is browser‑based; no data is transmitted or stored server‑side. Clipboard actions and file downloads stay on the device.

Step‑by‑Step Guide:

GlusterFS capacity planning converts brick counts and sizes into projected usable space, with protection and headroom applied.

Enter Total bricks and either a single size or per‑brick sizes.
Pick Volume type: Distributed, Replicated, Replicated (arbiter), or Dispersed (EC).
For replication, set replica and, if used, arbiters.
For EC, set data k and redundancy m.
Adjust Groups and Per group to match topology.
Open Advanced and set overhead and target fill.
Read the projected usable capacity and the breakdown.

Example: 12 × 10 TB, replication 3, overhead 3 %, fill 90 % → ~34.92 TB usable.

Tip: Keep units consistent when comparing designs.

You now have a defensible capacity estimate for planning and communication.

FAQ:

Is my data stored?

No. Calculations run in your browser, and any clipboard copies or downloads remain on your device. No server storage is used.

Clipboard and file saves are local.

How accurate is the estimate?

It models space, headroom, and protection efficiency. Small files, metadata growth, and rebalancing can shift results. Treat outputs as planning figures.

Adjust overhead and fill to reflect practice.

Which units are supported?

SI units MB, GB, TB, PB and IEC units MiB, GiB, TiB, PiB. Display formatting uses your locale separators with up to two decimals.

Choose one unit set and stick with it.

How are heterogeneous bricks handled?

Enter per‑brick sizes. The calculation uses the largest bricks first to fill active sets before summing capacity.

Zeros or blanks are ignored in totals.

What does “protected efficiency” mean?

It is the usable fraction after protection: 1 for distributed, 1 ⁄ r for replication, (r − a) ⁄ r with an arbiter, and k ⁄ (k + m) for erasure coding.

Higher protection lowers usable fraction.

Can I use it without a network?

The calculation itself does not require a network. Once the page is loaded, results compute locally.

Reloading assets may require connectivity.

How do I size EC 8+2?

Choose Dispersed, set data k = 8 and redundancy m = 2, then set groups and bricks per group accordingly. Efficiency will be 8 ⁄ 10.

Ensure enough bricks to fill groups.

What does a “borderline” result mean?

When usable space is close to your need, increase target fill conservatively or add bricks. Avoid operating at 100 % fill.

Leave headroom for growth and repairs.

Does licensing or cost affect use?

No licensing terms are embedded in this package. The calculator focuses purely on capacity planning logic.

Check your environment’s policies separately.

Troubleshooting:

Usable shows zero — check that brick sizes are positive and mode efficiency is not zero.
Groups used is lower than expected — increase brick count or reduce per‑group requirement.
Replicated with arbiter looks small — arbiter bricks reduce capacity by design.
Numbers look different after unit changes — keep a single unit set for comparisons.
CSV or JSON seems unformatted — your spreadsheet or editor may not auto‑format numbers.
Copy buttons do nothing — allow clipboard access in the browser.

Blocking: EC shows zero efficiency — ensure both k and m are at least 1 and that enough bricks exist to fill groups.

Advanced Tips:

Tip Model realistic overhead by sampling a few nodes and averaging.
Tip Keep per‑group brick counts identical to simplify maintenance and rebalancing.
Tip Lower target fill to reserve space for healing and upgrades.
Tip For mixed capacities, place smaller bricks in separate groups to avoid waste.
Tip Snapshot your inputs to document decisions and assumptions.
Tip Validate planned groups against actual rack or fault‑domain layout.

Aim for predictable behavior during failures and repairs, not maximum headline capacity.

Glossary:

Brick: A storage unit contributed by a node to a volume.
Replica width r: Bricks in a replication set.
Arbiter a: Tie‑breaker brick without full data copy.
EC k+m: Erasure coding data and redundancy bricks.
Efficiency η: Usable fraction after protection.
Target fill t: Planned occupancy to leave headroom.
Overhead f: File system and metadata space cost.
Groups: Number of sets formed across bricks.