GlusterFS Volume Capacity Calculator

A GlusterFS volume rarely turns raw disk size into payload space one-for-one. Brick count, brick order, volume type, replica width, erasure-code redundancy, and empty-space policy all change the planning number before applications write a byte. A cluster that looks large in inventory can still be short on safe usable capacity if one protected set is bottlenecked by a smaller brick or if the next expansion does not complete a full set.

GlusterFS stores data in bricks, which are storage directories exported by servers and combined into a volume. Distributed volumes spread files across active bricks for scale, but they do not create redundant copies. Replicated and arbiter volumes group bricks into mirrored subvolumes. Dispersed volumes use erasure coding, where data fragments and redundancy fragments share the same set. In every protected layout, the set is the unit that decides capacity, tolerance, and growth.

Capacity planning also has an operational side. A full-looking but technically valid layout may leave too little room for self-heal, rebalance, metadata growth, or a degraded rebuild. Administrators usually need three numbers at once: the balanced raw basis, the payload capacity after protection overhead, and the lower ceiling that leaves recovery space intact.

Raw physical capacity

The total size of the bricks before Gluster layout, filesystem overhead, fill policy, and recovery space are considered.

Balanced data basis

The set-limited capacity after each protected group is capped by its smallest data member.

Usable capacity

The amount available for payload data after the layout efficiency and selected reserves are applied.

Mixed brick sizes are one of the easiest ways to overestimate a GlusterFS volume. If a replica set contains two 10 TB bricks and one 6 TB brick, that set behaves like a 6 TB set for balanced mirrored payload capacity. The extra space on the larger members still exists physically, but it cannot safely become mirrored data inside that set. The same smallest-member limit matters for dispersed sets because each member has to keep pace with the others.

Expansion planning has another common trap: protected volumes grow in groups. Adding one spare brick to a distributed-replicated or distributed-dispersed design usually does not add protected usable space until enough bricks exist to form the next complete set. Brick order also matters because consecutive bricks form the protected subvolumes in the create command, so a best-case sorted estimate can differ from the live placement.

A good estimate also separates ordinary fullness from emergency headroom. A volume that looks acceptable at 85% full may still be too tight if it must heal a failed brick, rebalance after an expansion, or keep enough room for filesystem metadata. The planning number should be treated as a ceiling for safe operation, not as a promise that every raw byte can hold user data.

How to Use This Tool:

Start with the brick inventory, then choose the GlusterFS geometry that matches the volume you are planning or auditing. Keep the same unit system throughout one run so set comparisons stay meaningful.

1. Set Total bricks. For identical members, leave Heterogeneous bricks off and enter one Capacity per brick.
2. Turn on Heterogeneous bricks when sizes differ. Enter the per-brick rows in the create order you want to evaluate, or use Largest first estimate only as a planning comparison.
3. Choose Volume type. Distributed uses every active brick as raw space, Replica applies the replica width, Arbiter separates data bricks from arbiter members, and Dispersed uses k data bricks plus m redundancy bricks.
4. For protected layouts, set Active sets to model the complete sets currently in service. Bricks that cannot complete a set are reported as excluded rather than silently folded into usable capacity.
5. In Arbiter mode, choose the sizing basis. Use an average file size when file count is unknown, switch to Estimated files when namespace scale is known, and enable Shard files only when Gluster sharding changes the effective object size.
6. Open Advanced when you need an operating ceiling. Adjust Filesystem overhead, Target fill, Heal reserve, and Planned failed data bricks to match the runbook assumption you want to test.
7. Use the result tabs to compare the headline number with the set map, capacity slices, physical split chart, recovery envelope, and structured report.

Stop on any input alert. Invalid dispersed geometry, too few bricks for a complete protected set, blank capacity entries, or zero-limited sets make the result unsafe to use until the layout is corrected.

Interpreting Results:

Planned usable capacity is the normal payload target after the selected layout, filesystem overhead, and target fill are applied. Recovery-safe usable can be lower when the modeled heal reserve and failed-brick headroom require more empty space than the target fill leaves behind.

Equalized data raw is the best first check for protected layouts. If it is much lower than Active physical, the current grouping is losing capacity to uneven members. Mismatch / stranded names that gap directly, while Unused / excluded points to bricks that do not belong to a complete active set.

• Arbiter sizing risk means the smallest active arbiter is below the estimated metadata footprint for the current file-count or average-file-size assumption.
• Recovery-safe fill shows the fill level left after heal reserve and rebuild headroom are held back.
• Maximum safe fill is the highest fill ceiling that still respects the current recovery reserve.
• Stripe size appears for dispersed layouts and follows the selected k value.

A passing capacity result does not prove that the cluster topology is safe. Replica, arbiter, and dispersed sets still need failure-domain placement, quorum review, compatible GlusterFS syntax, healthy bricks, and a tested recovery process.

Technical Details:

GlusterFS capacity math is driven by subvolumes. A distributed volume can use active brick capacities directly, but protected layouts first divide the brick list into replica, arbiter, or dispersed sets. Each complete set contributes a balanced data basis, and any incomplete tail remains outside the protected calculation.

The smallest data member controls each protected set. Replica sets mirror the same payload across all members. Arbiter sets use data members for payload and keep arbiter members as metadata participants rather than payload copies. Dispersed sets spread data with erasure-code redundancy, so the protected set contributes only the data-fragment share after the smallest member has capped the set. Filesystem overhead, target fill, heal reserve, and rebuild headroom are applied after that set geometry is known.

Formula Core:

The formulas below describe the main capacity path after complete sets have been selected and mixed-size set limits have been applied.

Recovery headroom is calculated from two reserves. The heal reserve holds a percentage of effective balanced raw for self-heal, rebalance, and maintenance work. Failed-brick headroom adds the largest recoverable data-member basis for the requested number of concurrent failures, clamped to the tolerance that the selected layout can represent. Distributed mode has no redundant rebuild basis, so its recovery-safe fill only reflects the heal reserve.

For 12 identical 10 TB bricks in replica 3, four complete sets produce 120 TB of equalized data raw. With 0% filesystem overhead, an 85% target fill, and 33.3% payload efficiency, planned usable capacity is 34 TB. If one planned data-brick failure and a 5% heal reserve require more unused capacity than the target fill leaves, recovery-safe usable drops below the planned usable figure.

Accuracy Notes:

This is a deterministic capacity estimate, not a GlusterFS simulator. It does not model performance, failure domains, heal duration, split-brain resolution, brick filesystem tuning, snapshots, quotas, geo-replication, thin provisioning, or application write patterns.

• Use decimal units such as TB or binary units such as TiB consistently in a single run.
• Use As entered when checking an existing volume because brick order decides set membership.
• Treat Largest first estimate as a best-case comparison for mixed bricks, not proof of live placement.
• Use the arbiter estimate as a namespace planning check, then verify the actual arbiter guidance for your GlusterFS release and workload.
• Check real arbiter support and command syntax for the GlusterFS version you operate, especially when modeling anything beyond the common 2 data + 1 arbiter layout.

Worked Examples:

Replica 3 with identical bricks

With Total bricks set to 12, Capacity per brick set to 10 TB, Volume type set to Replica, and Replica width set to 3, the calculator forms four complete replica sets. At the default 85% target fill and 0% filesystem overhead, Planned usable is 34 TB because only one payload copy from each three-member set counts toward usable space.

Mixed-size bricks that strand space

A replica set containing 10 TB, 10 TB, and 6 TB data members is capped by the 6 TB member. Gluster Set Map reports the smaller limit and Mismatch / stranded identifies the extra raw capacity that cannot contribute to balanced payload space.

Arbiter namespace risk

In Arbiter mode, a 2 data + 1 arbiter set reports Arbiter minimum, recommended headroom, and Smallest arbiter. If the file-count estimate is high enough that the smallest arbiter falls below the minimum, the summary badge changes to Arbiter sizing risk.

Invalid dispersed geometry

Setting dispersed k to 2 and m to 2 triggers an alert because redundancy must be less than data bricks. Increase k, reduce m, or choose another volume type before using the capacity results.

FAQ:

Glossary:

Brick

A storage directory exported by a GlusterFS server and used as a member of a volume.

Protected set

A replica, arbiter, or dispersed group that must be complete before it contributes protected capacity.

Equalized data raw

The balanced raw basis after each protected set is capped by its smallest relevant member.

Arbiter

A metadata-holding member used with replicated data bricks to help avoid split-brain without storing full payload copies.

Recovery-safe fill

The fill level that remains after heal reserve and modeled rebuild headroom are held back.

References:

• Setting Up Volumes, Gluster Docs.
• Arbiter volumes and quorum options in gluster, Gluster Docs.
• Managing Volumes, Gluster Docs.
• Creating Arbitrated Replicated Volumes, Red Hat Documentation.
• How to create a GlusterFS volume, simplified.guide.
• How to create a distributed dispersed GlusterFS volume, simplified.guide.
• How to create high availability storage with GlusterFS, simplified.guide.