The Mathematics of Data Integrity: Mastering ZFS Capacity Planning
For home lab enthusiasts and enterprise DevOps engineers, OpenZFS is the ultimate final destination for data storage. However, many architects encounter a jarring shock upon completing their first Vdev: the usable capacity is significantly lower than the sum of the physical drives. This is not a bug; it is a clinical manifestation of the ZFS Capacity Tax. This ZFS Capacity Architect (our technical Canvas planner) is designed to demystify the loss vectors of parity, slop space, and the fundamental lie of decimal marketing.
The Core Formula of Storage Reality
To calculate true usable space, we must apply the Triple Filter of storage math. Here is the logic engine in plain English:
1. The Marketing to Binary Conversion (LaTeX)
Hard drive manufacturers define 1 Terabyte as $10^{12}$ bytes. Computers define 1 Tebibyte as $2^{40}$ bytes. The conversion factor is roughly $0.9095$:
2. The Parity Subtraction
"Your Net Capacity equals your Binary Disk Size multiplied by the number of Data Disks ($N - P$), where $N$ is total disks and $P$ is the parity level (1, 2, or 3)."
Chapter 1: Deciphering RAIDZ Topologies
ZFS organizes disks into Virtual Devices (Vdevs). The choice of topology is a three-way battle between Capacity, Performance, and Redundancy.
1. RAIDZ1 (The Risky Entry)
RAIDZ1 allows for one drive failure. While it offers high efficiency, it is increasingly discouraged for drives larger than 4TB. During a Resilver (rebuild), the remaining drives are under intense stress. If a second drive fails during this window, the entire Pool is lost. Linguistically, RAIDZ1 is a gamble on the quality of your drive hardware.
2. RAIDZ2 (The Professional Standard)
RAIDZ2 uses double parity, meaning you can lose two drives simultaneously without data loss. For arrays containing 6 or more drives, RAIDZ2 is the industry-standard recommendation for balancing safety and usable TiB. It provides a massive peace-of-mind buffer during the long rebuild times associated with high-capacity 18TB+ drives.
3. Mirrors (The Speed King)
Mirroring (RAID 1 equivalent) provides 50% capacity efficiency but offers the highest IOPS (Input/Output Operations Per Second). In ZFS, read performance scales with the number of mirrors. If you are building a pool for Virtual Machines or Databases, Mirrors are the only logical choice, despite the "Girl Math" pain of losing half your storage to redundancy.
THE "SLOP SPACE" OVERHEAD
ZFS reserves a small portion of every pool (roughly 1.6% to 3.2%) as 'Slop Space'. This reserve ensures the filesystem remains operational even when the pool is completely full, allowing you to delete files to free up space. Without slop space, a 100% full COW filesystem would be permanently locked.
Chapter 2: The 80% Rule - Maintaining Performance Velocity
Because ZFS is a Copy-On-Write filesystem, it never overwrites data. It always writes to new blocks. As a pool fills up, finding contiguous free space becomes computationally expensive. This leads to Fragmentation. To maintain high write speeds, storage architects adhere to the 80% Threshold. If your pool exceeds 80% utilization, latency spikes and throughput drops. Our calculator provides the "Effective Usable Space" to help you plan your hardware purchases around this performance cliff.
| Topology | Minimum Disks | Optimal Disks (Best Practice) |
|---|---|---|
| RAIDZ1 | 3 | 3, 5, 9 (Power of 2 + 1) |
| RAIDZ2 | 4 | 6, 10 (Power of 2 + 2) |
| Mirror | 2 | Any pair (Pairs of Vdevs) |
| RAIDZ3 | 5 | 7, 11 (Power of 2 + 3) |
Chapter 3: Physical Drive Selection - CMR vs. SMR
When using the ZFS Architect tool, your inputs assume high-quality hardware. It is critical to avoid SMR (Shingled Magnetic Recording) drives for ZFS pools. SMR drives overlap data tracks to increase density, which causes disastrously slow write speeds during the ZFS resilvering process. Always verify that your drives use CMR (Conventional Magnetic Recording) technology to ensure the survival probability projected by our engine matches real-world performance.
Chapter 4: Advanced Tuning - Recordsize and Compression
The "Effective Usable Space" can actually exceed the physical TiB if you use LZ4 or ZSTD Compression. For text-heavy datasets, ZFS can achieve 2x or 3x compression ratios, effectively doubling your pool size. However, for media servers (storing encoded video), compression provides near-zero benefit. Adjust your expectations based on your Dataset Entropy.
Frequently Asked Questions (FAQ) - Storage Engineering
Why is there a difference between TB and TiB?
What is "vdev expansion" in OpenZFS?
Is my data private while using this tool?
Build Your Fortress
Stop guessing about overhead. Quantify your parity, calculate your slop, and architect a storage pool that survives the tests of time and hardware failure.
Adjust Hardware Inputs