Usable storage after RAID

01

Normalize bytes, TB and TiB

Drive labels and the Tungsto catalogue use decimal units: one TB is 1,000,000,000,000 bytes. One TiB is 1,099,511,627,776 bytes. The same byte count therefore appears as a smaller number in TiB. Convert from source bytes rather than applying a rounded percentage repeatedly, and label every worksheet column with its unit.

For example, the 12 × 16 TB catalogue array contains 192 TB raw before redundancy, while 24 × 20 TB contains 480 TB raw. Those figures exclude the separate NVMe boot pair. They are inventory facts, not claims about filesystem-visible or writable capacity.

02

Model the real topology, not one aggregate row

Use the smallest participating device size when members differ unless the selected implementation documents otherwise; larger portions may remain unusable. Separate boot, cache, log, spare and data devices. For ZFS, identify every top-level vdev and its redundancy. Data is striped across top-level vdevs, so one non-redundant vdev can make an otherwise mirrored pool vulnerable to that single device.

The simple parity formula approximates a RAIDZ group as data devices times device size, but actual allocation depends on record size, sector geometry and parity behaviour. OpenZFS therefore describes its usable pool property as a heuristic, not an exact promise.

• OpenZFS pool capacity properties ↗

03

Apply a capacity waterfall

Start with raw bytes, subtract redundancy and any dedicated hot spares, then read the created filesystem or pool's own available property. From that result, reserve space required by policy, snapshots, copy-on-write behaviour, temporary replication or restore work and application growth. Do not assume compression or deduplication savings; both depend on data and configuration and can disappear from a conservative forecast.

Keep two outputs: theoretical capacity for comparing layouts and operational capacity for admitting data. The second should include an alert threshold and a stop-admission threshold chosen by the operator. A filesystem filling to its last reported byte can impair maintenance and recovery even if the arithmetic originally looked correct.

04

Validate the created pool before committing data

After creating the selected layout, record device membership, redundancy, health and the implementation's reported available capacity. On ZFS, distinguish pool-level estimates from dataset availability because quotas, reservations and parity can make them differ. The TrueNAS capacity calculator is useful for planning ZFS geometry, but its inputs still need to match the actual drives, ashift, record size, spares and reservation policy.

Create an acceptance record before production: raw bytes, layout diagram, calculated value, reported value, reserve, snapshot policy and backup destination. Investigate any unexplained gap rather than changing units until numbers appear to match.

05

Keep capacity and recovery separate

A larger usable figure does not prove a safer design. State tolerated device failures, monitoring, spare procedure, scrub or consistency-check policy and restore source beside the capacity result. RAID and ZFS redundancy remain inside one chassis; they do not protect against deletion, compromise or loss of the server.

The expected result is a reproducible capacity worksheet that another operator can recalculate from device bytes and topology. Use the calculator for a shortlist, then replace its estimate with observed properties from the deployed pool before offering application capacity.