GlusterFS Volume Capacity Calculator

Raw brick capacity is not the same as usable GlusterFS capacity. Replication stores full copies, dispersed volumes spend space on erasure-code fragments, and arbiter layouts add a metadata-only voting member. Operating reserve, incomplete protected sets, and unequal brick sizes can reduce the payload further.

A brick is an exported directory on a storage server. Protected volumes arrange bricks into fixed-width replica or disperse sets, then distribute files across those sets. Capacity therefore depends on set geometry and brick order, not only on the sum printed on the disks. A tail of bricks that cannot complete a set contributes no protected capacity, while a larger data brick paired with smaller members is limited by the smallest member in its set.

Planning fill is an operating ceiling, not a promise that every remaining byte is safe to consume. Self-heal, rebalance, and replacement of a failed brick need unallocated capacity while the cluster is degraded. A capacity plan can look adequate on a healthy day yet leave too little headroom for recovery.

This estimate is most useful before volume creation or expansion, when brick grouping, size mismatch, and recovery reserve can still be changed. It does not inspect a live volume, validate quorum or rack placement, predict heal duration, or account for current usage, snapshots, quotas, compression, and workload-specific filesystem effects.

How to Use This Tool:

Model the brick estate and protected-set order that will actually be used, then compare planned payload with recovery-safe payload.

1. Enter Total bricks and one common Capacity per brick. Turn on Heterogeneous bricks when capacities differ, and list one positive value for every brick in create order.
2. Choose Distributed, Replica, Arbiter, or Dispersed. Set replica width or the k+m geometry, then limit Active sets if only part of the estate is in service.
3. Set Target fill and Heal reserve. In Advanced options, add filesystem overhead, planned failed bricks, or largest-first ordering only when those assumptions belong in the plan.
4. For an arbiter layout, choose an Arbiter sizing basis and enter either average file size or estimated file count. Include the shard block size when sharding changes the effective file count.
5. Read Capacity ledger and Gluster set map together. Resolve excluded tail bricks, set mismatch, an undersized arbiter, or a recovery warning before treating Planned usable as deployable capacity.

Interpreting Results:

Planned usable is payload after smallest-member equalization, filesystem overhead, target fill, and protection efficiency. Recovery-safe usable may be lower when the heal reserve and modeled failed-brick replacement need more unallocated capacity than the target fill leaves.

• Mismatch / stranded identifies data-member capacity above the smallest member limit within protected sets.
• Outside active sets identifies bricks excluded by incomplete or intentionally inactive sets.
• Maximum safe fill is the highest modeled fill after heal and failed-brick headroom. Lower target fill or add raw capacity when the requested fill exceeds it.
• A satisfactory capacity result does not prove that bricks occupy separate failure domains or that quorum and live heal behavior are safe. Verify the proposed create order against the actual hosts and racks.

Technical Details:

Protected capacity is calculated one complete set at a time. Within each set, the smallest data member sets the usable extent for every data member; any larger remainder is stranded. Decimal units such as TB use powers of 1000, while binary units such as TiB use powers of 1024. Every brick in one plan shares the selected capacity unit.

Formula Core:

Let B be equalized data-member capacity across the active sets, o the filesystem-overhead ratio, f target fill, and e protection efficiency. Planned usable capacity U is:

Recovery reserve combines a percentage holdback with the equalized raw capacity needed for the modeled failed data bricks. If B_e is capacity after filesystem overhead, H is heal reserve, and R is failed-brick headroom, the safe fill and safe payload are:

Rule Core:

Replica and arbiter sets use the selected replica width. A dispersed set uses k+m members and requires m to be smaller than k. Available protected sets are the whole-number result of brick count divided by set width; partial sets remain outside active capacity. Largest-first ordering sorts bricks before grouping and can change which capacities are stranded.

For an arbiter estimate, file count is entered directly or rounded up from the largest active data brick divided by effective file size. Sharding uses the smaller of average file size and shard-block size. Minimum arbiter bytes equal 4096 bytes per estimated file, and the displayed recommended size adds 25%. The sizing verdict compares the smallest active arbiter with the minimum, not the recommendation.

A dispersed stripe is reported as 512 bytes × k. Numeric results retain full calculation precision and are rounded only for display.

Accuracy Notes:

The arithmetic models capacity placement, not live cluster behavior. Filesystem allocation, inode limits, file-size distribution, sharding, current utilization, and concurrent failures can change the real margin.

• Confirm brick order and failure-domain separation before creating or expanding a volume.
• Treat failed-brick reserve as capacity headroom, not a forecast of heal time or service availability.
• For arbiters, check both byte capacity and inode availability; the 4 KiB-per-file estimate does not guarantee that the underlying filesystem has enough inodes.

Worked Examples:

References:

• Setting Up Volumes, GlusterFS Documentation.
• Arbiter volumes and quorum options, GlusterFS Documentation.
• How to choose a GlusterFS volume type, Simplified Guide.
• How to create a distributed dispersed GlusterFS volume, Simplified Guide.