dRAID Capacity Calculator

The dRAID Capacity Calculator estimates the usable storage capacity of a distributed RAID (dRAID) storage pool. It calculates raw, zpool, and usable file system capacity based on the selected dRAID parity level, the number of vdevs, redundancy group configuration, and the number of distributed spares.

To estimate the usable capacity of a dRAID pool provide the following values:

• RAID type - Select the desired dRAID type. Supported RAID levels are:
  • dRAID1 (distributed single parity);
  • dRAID2 (distributed double parity);
  • dRAID3 (distributed triple parity).
• Disk capacity - we expect this number to be in gigabytes (GB) or terabytes (TB) (powers of 10), in-line with the way disk capacity is marked by the manufacturers. This number will be converted to tebibytes (TiB) (powers of 2) for calculations. The results will be presented in both tebibytes (TiB) and terabytes (TB). Note: 1 TB = 1000 GB = 10¹² B and 1 TiB = 1024 GiB = 2⁴⁰ B.
• Disk sector size - Choose the sector size. Supported sector sizes and corresponding ashift values:
  • 512 B (ashift=9);
  • 4 KiB (ashift=12).
• Number of dRAID vdevs - the number of top-level vdevs in the pool.
• Child devices per vdev - the number of child devices per vdev (C).
• Spare devices per vdev - the number of distributed spare devices per vdev (S).
• Data devices per group - the number of data devices per redundancy group (D).

Click Calculate to estimate the resulting raw, zpool and usable ZFS capacity.

The tool models the capacity calculations performed by OpenZFS, including capacity adjustments and allocations for partitioning, ZFS labels, dRAID layout, parity, and slop space. It provides the following results:

• Total raw storage capacity - the total storage capacity of all disks in the pool, excluding spares.
• Zpool storage capacity - calculated by subtracting the space overhead for drive partitioning and metaslab allocation from the total raw pool capacity. This value should be pretty close to the ALLOC value reported by the zpool list command.
• Reservation for parity - space allocated for storage of parity blocks.
• Slop space allocation - equals to 1/32 of the capacity of the pool or at least 128 MiB, but never more than the lesser of 128 GiB or half the pool size.
• ZFS usable storage capacity - calculated by subtracting the parity reservation and the slop space allocation from the zpool storage capacity. This number should be reasonably close to the sum of the USED and AVAIL values reported by the zfs list command.

Notes:

• This tool estimates capacity for dRAID pools created using whole disks.
• The calculations are based on the OpenZFS implementation and take into account whole-disk partitioning, ZFS labels, dRAID geometry, distributed spare allocation, parity overhead, metaslab allocation, and slop space reservation.
• Small discrepancies between the calculated and actual capacity values may occur due to approximations of certain internal calculations and implementation-specific differences between ZFS versions and platforms.
• Compression, deduplication, and snapshots are not considered when estimating usable file system capacity.
• The calculator does not support dRAID configurations where the group width (D + P) exceeds the number of children minus the number of distributed spares (C - S).

OpenZFS typically represents a dRAID configuration using the format dRAIDP:Dd:Cc:Ss, where:

• P (Parity) - The distributed parity level of a dRAID redundancy group. This ranges from 1 to 3 and is similar to the RAIDZ parity level:
  • dRAID1 - single parity
  • dRAID2 - dual parity
  • dRAID3 - triple parity
• D (Data) - The number of data devices per redundancy group.
• C (Children) - The total number of devices in the dRAID vdev.
• S (Distributed Spares) - The number of distributed hot spares.

A dRAID vdev is comprised of multiple redundancy groups, each organized into a set of data (D) and parity (P) columns, similar to RAIDZ. However, unlike RAIDZ, the data and parity columns are not fixed to a specific set of physical devices. Instead, they are distributed across all of the child devices (C) in the dRAID vdev. The distributed parity and spare capacity (S) are allocated across all drives in the vdev. To ensure an even distribution and avoid hot spots, a predetermined permutation mapping is applied to the order of the dRAID columns. As a result, every drive in the dRAID vdev participates in storing data, parity, and a portion of the distributed spare space.

For example, the configuration dRAID2:8d:24c:2s means:

Unlike traditional RAIDZ, dRAID distributes both parity and spare capacity across all drives in a vdev, allowing a failed drive to be rebuilt using all remaining disks simultaneously. This significantly reduces rebuild times for large storage systems while maintaining the data integrity and redundancy features of OpenZFS.

Although dRAID and RAIDZ both provide parity-based data protection in OpenZFS, they are designed for different deployment scenarios.

When to use RAIDZ:

For small and medium-sized storage systems, RAIDZ is usually simpler to design, requires fewer configuration parameters, and provides excellent capacity, performance, and reliability. Most home NAS systems, virtualization servers, and small business storage arrays continue to use RAIDZ1, RAIDZ2, or RAIDZ3.

When to use dRAID:

dRAID was introduced to address one of the biggest challenges of very large storage systems: rebuilding failed drives. As drive capacities continue to increase, rebuilding a conventional RAIDZ vdev can take many hours or even days. During this period the pool operates with reduced redundancy.

Instead of dedicating one or more idle hot spare drives, dRAID distributes spare capacity across every drive in the vdev. When a drive fails, OpenZFS immediately begins rebuilding data into this distributed spare space using all remaining drives simultaneously. The rebuild proceeds sequentially, greatly reducing resilver time compared to conventional RAIDZ.

In short, dRAID is primarily intended for large pools containing dozens or hundreds of drives, where minimizing rebuild time after a drive failure is more important than maximizing storage efficiency or configuration simplicity.