| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Brick | Capacity | Status |
|---|---|---|
| {{ brick.label }} | {{ brick.capacityDisplay }} | {{ brick.status }} |
| Slice | Value | Share |
|---|---|---|
| {{ slice.name }} | {{ formatCap(slice.value) }} {{ unit }} | {{ formatPercent(slice.share, 1) }} |
| Guardrail | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
GlusterFS capacity narrows in stages. Raw brick space is first limited by the volume geometry you can actually form, then by the smallest data-bearing member inside each protected set, and only after that by the operating headroom you want to keep for ordinary fill, heal work, and degraded-state rebuilds. This calculator is built around that narrowing process, so the headline number is closer to a storage plan you can run than to the raw disk total you bought.
It can model distributed, replicated, arbiter, and dispersed layouts from either one shared brick size or a per-brick list. You can restrict the plan to complete sets only, switch between real brick order and a largest-first planning estimate, keep space back for filesystem overhead and fill targets, and compare planned usable space with a stricter recovery-safe floor.
Use it before an expansion, when mixing new and old brick sizes, when comparing replica and erasure coding, or when a team needs a clearer explanation for why a pool that looks large on paper still needs more breathing room. It does not inspect a live cluster. It is an input-driven planning model that returns a plan ledger, a set map, a capacity split chart, a recovery view, and a JSON snapshot.
The model starts by building the active brick list. In uniform mode it repeats one capacity across the whole brick count. In per-brick mode it keeps one value per member and treats blank or zero rows as zero-capacity bricks. Protected layouts then activate only the bricks needed for the selected number of complete sets. If you choose the as-entered ordering, the list stays in the same order you provided. If you switch to the largest-first estimate, the tool sorts larger bricks to the front before it forms the active sets.
Once the active list is known, the tool equalizes protected sets before it calculates usable space. Replica and arbiter layouts are limited by the smallest data-bearing member in each set. Dispersed layouts are limited by the smallest member in the whole k + m group, because the stripe cannot advance farther than its shortest participant. This is why mixed brick sizes can leave capacity stranded even when the raw totals still look generous. Official Gluster guidance makes the same point for dispersed sets: uneven members eventually stop the whole set when the smallest brick fills first.
Recovery logic is separate from protection logic. Filesystem overhead reduces the equalized pool first. Target fill expresses how full you intend to run in ordinary service. Heal reserve keeps additional free space for self-heal or rebalance activity. Planned failed data bricks then reserve rebuild headroom from the largest recoverable data members. The smaller of your requested fill and the computed maximum safe fill becomes the recovery-safe result. In distributed mode, rebuild planning is only advisory because there is no redundant copy or coding layer to rebuild from.
| Mode | What becomes active | How usable data is derived | Fault-tolerance cue shown by the tool |
|---|---|---|---|
| Distributed | All active bricks contribute directly | Post-overhead raw pool multiplied by target fill | No redundancy |
| Replicated | Only full replica sets of the chosen width | Each set collapses to its smallest member, then mirror efficiency is applied inside that equalized pool | replicaWidth - 1 data-member failures per set |
| Replicated with arbiter | Only full data-plus-arbiter sets | Data-bearing members are equalized by the smallest data brick; arbiter footprint is reported separately instead of counted as usable data | dataMembers - 1 data-member failures per set |
| Dispersed | Only full k + m sets |
Each set is capped by its smallest member and keeps k / (k + m) of that equalized pool as usable data |
m member failures per set |
Arbiter mode adds one more check. The tool estimates arbiter storage from namespace size, not from file payload. If you supply average file size, it derives file count from the largest active data brick. If sharding is enabled and the shard block is smaller than the average file, it uses the shard size instead. It then applies the 4 KB per file rule, shows a minimum and a 25 percent recommendation, and compares those figures with the smallest active arbiter brick. In dispersed mode it also reports stripe size as 512 × k bytes so different geometries can be compared more deliberately.
If your bricks are not identical, turn on per-brick entry early. That is the fastest way to uncover the two Gluster patterns that usually break spreadsheet estimates. One is the incomplete-set problem, where leftover bricks sit outside the current geometry. The other is the bottlenecked-set problem, where a smaller data brick caps its whole set and strands the extra capacity on larger neighbors.
Use the as-entered ordering when you want the plan to mirror a real build or an existing volume, because official Gluster documentation is explicit that brick order determines how replica subvolumes are formed in distributed-replicated layouts. Use the largest-first mode only when you are testing a best-case planning scenario or a future rebuild order. It is useful for exploration, but it should not be mistaken for the current on-disk arrangement.
Arbiter layouts deserve one extra pass. Arbiter bricks do not carry full file payload, so a small raw footprint can still be fine, but namespace scale matters a great deal. If you already know rough file count, use that input directly. If not, estimate from average file size and enable shard sizing when shard blocks are smaller than the files you usually store. That gives a more honest minimum for the arbiter members than raw brick size alone.
Dispersed layouts need a different instinct. Watch both the efficiency and the stripe note. A 4+2 set often becomes the comparison point because it balances redundancy and usable percentage well, but the right choice still depends on how many simultaneous brick losses you want to survive, how mixed the brick sizes are, and how much free space you need to keep for rebuild work.
k and m values as needed.Planned usable capacity is the figure most people expect from a capacity calculator. Recovery-safe usable is the figure this tool wants you to respect when space must still be available for heal and rebuild work. If those two numbers stay close, your target fill fits inside the reserve envelope. If they separate sharply, the layout may still function, but it is operating closer to the edge than the headline total suggests.
| Cue | What it means |
|---|---|
| Mismatch / stranded | Larger members in a protected set cannot contribute beyond the smallest data-bearing member in that same set. |
| Unused / excluded | Some bricks do not land in any complete protected set under the current geometry or active-set count. |
| Recovery reserve | Heal reserve and rebuild headroom are consuming part of the equalized pool before the safe fill limit is applied. |
| Arbiter sizing risk | The smallest active arbiter is below the estimated namespace-driven minimum for the selected file-count model. |
| Stripe size | An informational check for dispersed layouts that helps compare one k geometry with another. |
The safest cross-check is whether the dominant warning sounds like the real storage concern. If you are mixing old and new brick sizes, stranded space should become the main story. If you are planning maintenance windows or tolerating concurrent failures, recovery reserve should matter more than the raw efficiency number. If you are considering arbiters to save space, the arbiter sizing line should become part of the decision instead of an afterthought.
Distributed mode is the clearest example of why the recovery panel matters. The tool can still reserve space for heal work and planned failures, but it cannot turn that reserve into true redundancy. A good-looking distributed result is still a capacity plan without mirrored or coded protection behind it.
Imagine two replica-3 sets built from six bricks. One set contains 8 TB, 8 TB, and 8 TB members. The other contains 8 TB, 8 TB, and 4 TB. The smaller member caps the second set, so 4 TB on each larger partner in that set can no longer contribute to balanced data. The raw pool still looks large, but the equalized pool drops and the tool reports the lost capacity as mismatch instead of hiding it.
Suppose you have eight bricks and want a 4+2 dispersed layout. One complete set needs six bricks, so two members remain outside the active geometry unless you change the design or add more bricks. The calculator does not silently average those leftovers into the result. It shows one active set, two excluded members, and a raw-versus-usable split that matches the complete geometry you can actually run.
Consider a replicated-with-arbiter design with large data bricks but a very file-heavy namespace. If you estimate 25 million files, the 4 KB per file rule yields roughly 100 GB as a minimum arbiter target, and the tool raises that to about 125 GB as a safer recommendation. A 64 GB arbiter can therefore look roomy in raw percentage terms while still being undersized for metadata growth. The badge and summary detail call that out immediately.
No. It is a planning tool driven by the values you enter. It does not read current brick health, heal backlog, quorum state, or live volume options from a cluster.
Because protected sets are limited by their smallest active data-bearing member. If a zero-capacity brick lands inside a replica, arbiter, or dispersed set, that set can collapse to zero balanced data for planning purposes.
Not by default. It is a best-case planning estimate. The as-entered mode is the safer choice when you want to mirror how bricks were actually arranged into sets.
Because arbiter members are meant to hold names, directory structure, and metadata rather than full payload blocks. The tool tracks that footprint separately and checks whether it is large enough for the projected namespace.
No. It is a reserve model bounded by the layout's recovery cue. Live quorum, brick placement, and current cluster state still matter when failures actually happen.