RAID & ZFS Capacity Calculator

Choose a layout, enter how many drives it holds and how big each one is, and the calculator works out how much data the array can store. Classic RAID levels sit alongside ZFS mirrors and RAID-Z, and the ZFS figures follow the OpenZFS source code rather than the textbook, because ZFS reports noticeably less than the textbook on some layouts. The defaults describe a common home-server pool, six 12 TB drives in RAID-Z2. It stores 47.85 TB, appears in zfs list as 43.48 TiB, uses 66.5 percent of the raw space and survives any two drive failures. The breakdown table shows where the rest of the raw space goes, and the comparison table puts the same drives in every other layout.

How the capacity is worked out

Classic RAID keeps whole drives for data. A stripe uses every drive, a mirror keeps one drive's worth however many copies it holds, and parity costs one drive per group for RAID 5 and two for RAID 6:

usable = (drives − parity drives) × drive size

RAID 10 keeps half of its drives, RAID 50 gives up one drive in every span and RAID 60 two. These figures are the size of the block device the array presents, before a filesystem takes its own share.

ZFS takes four further steps, all of them in the OpenZFS source. Each disk loses 4.5 MiB to four 256 KiB labels and a 3.5 MiB boot area, and each vdev is split into equal metaslabs, which the source sizes at 16 GiB on vdevs from about 3 TB to 2 PB, with whatever is left at the end of the vdev never used. RAID-Z then stores a block of s sectors across w drives with p parity sectors in every row, and pads the total so that no gap too small to use is left between allocations:

allocated = s + p × ⌈s ÷ (w − p)⌉, rounded up to a multiple of p + 1

ZFS counts space as though every block were 128 KiB. It works out what a 128 KiB block allocates on the vdev, in 512-byte units, and scales all raw space by the deflate ratio:

r = ⌊131,072 ÷ units allocated for 128 KiB⌋, counted as r ÷ 512 of each raw byte

Finally the pool keeps back one thirty-second of its space, capped at 128 GiB, and counts the metaslab each large vdev keeps for the intent log as part of that reserve until the log metaslabs pass half of it. What remains is the free space zfs list reports. The usable figure converts it to data at the record size you choose, because each record is charged its own allocation at the same ratio:

usable = reported × record size ÷ (units allocated for a record × r)

A worked example with the defaults

Six 12 TB drives hold 72 TB raw. ZFS trims each drive to a whole number of 256 KiB units and sets aside 4.5 MiB, which leaves 11,999,995,232,256 bytes a drive and 71,999,971,393,536 bytes for the vdev. That is 4,190.95 metaslabs of 16 GiB, so ZFS creates 4,190 and never uses the last 16.32 GB.

A 128 KiB block is 32 sectors of 4 KiB. Six-wide RAID-Z2 has four data columns, so the block fills eight rows and needs 16 parity sectors, 48 in all, which is already a multiple of three. That is 384 units of 512 bytes, and 131,072 ÷ 384 is 341.33, rounded down to 341, so each 16 GiB metaslab counts as 11,442,061,312 bytes. One metaslab goes to the intent log, which leaves 4,189, or 47.93 TB.

A thirty-second of that is 1.5 TB, far over the cap, so the reserve is 128 GiB less the 10.66 GiB log metaslab: 117.34 GiB. zfs list therefore shows 47,804,797,943,808 bytes, which is 43.48 TiB or 47.80 TB. Because the ratio was rounded down, each 128 KiB record is charged 130,944 bytes rather than 131,072, so files written in full records fit 47.85 TB. That is 66.5 percent of the raw 72 TB, and any two of the six drives can fail without losing data.

Where RAID came from

Rebuilding lost data from parity is older than the name. Norman Ken Ouchi of IBM filed a patent on 31 May 1977, granted a year later as US 4,092,732, that reconstructs a failed unit's segment from the others and a check sum made by Exclusive-ORing them and kept on a different unit. The name came from Berkeley. David Patterson, Garth Gibson and Randy Katz wrote it up in a technical report dated December 1987 and presented "A Case for Redundant Arrays of Inexpensive Disks (RAID)" at the ACM SIGMOD conference in Chicago in June 1988, introducing five levels of RAID. Inexpensive did not last: by the mid-1990s the I was often read as independent, a reading the 1994 survey by Peter Chen and the Berkeley group noted in a footnote. That survey also set out P + Q redundancy, RAID level 6, which uses Reed-Solomon codes to survive any two disk failures with exactly two disks' worth of redundancy.

Where ZFS and RAID-Z came from

ZFS began at Sun Microsystems, where Jeff Bonwick and Matthew Ahrens had their first prototype running in 2001. It was integrated into Solaris on 31 October 2005, and its source appeared in OpenSolaris build 27 that November. Bonwick's post on RAID-Z, dated 18 November 2005, described a scheme like RAID-5 but with dynamic stripe width: every block is its own stripe, so every write is a full-stripe write, which together with copy-on-write eliminates the RAID write hole. The same per-block design is why RAID-Z pads. Ahrens' post on stripe width of June 2014 explains that each allocation must be a multiple of parity plus one sectors, so RAID-Z needs a little more space than RAID-5 or RAID-6. Double parity arrived as pool version 3 in Solaris 10 11/06 and triple parity as pool version 17, which Adam Leventhal argued for in ACM Queue in December 2009 because rebuild times grow as drive capacity outstrips throughput. OpenZFS was announced on 17 September 2013. Its 2.1 release in July 2021 added dRAID and the 128 GiB cap on slop space, and 2.3 in January 2025 added RAID-Z expansion.

Why the vdev width matters

Padding depends on how a 128 KiB block divides across the data columns. With 4 KiB sectors, these are the shares of raw space ZFS counts, against the textbook share:

Larger records recover most of the gap, because the padding is spread over more data. Twelve 12 TB drives in one RAID-Z2 vdev store 109.56 TB with 128 KiB records, 119.14 TB with 1 MiB records and only 95.87 TB with 16 KiB records, against 120 TB in theory, while zfs list shows 99.62 TiB in every case. OpenZFS 2.2 raised the default limit on record size from 1 MiB to 16 MiB. Small blocks cost the most, which matters for virtual machine disks stored as zvols with a small volblocksize.

What the figures leave out

The calculator assumes each drive holds exactly its labelled capacity and is given whole to ZFS. Partitioning takes a few more megabytes per disk, which changes the result only when a vdev ends within that distance of a metaslab boundary. The ZFS figures assume incompressible data, one copy of each block and files written in full records, and they leave out metadata such as indirect blocks. Compression fits more; small files fit less, because they are stored in smaller blocks that carry proportionally more parity and padding. The model follows OpenZFS 2.1 and later. Release 2.0 had no cap on slop space, so a large pool on it reserved a full thirty-second, and a RAID-Z vdev widened by the expansion feature keeps the parity ratio it was created with, so zfs list shows slightly less than this calculator gives for the new width.

Classic RAID figures stop at the block device. A filesystem keeps space for its own metadata, and ext4 also reserves 5 percent of its blocks for the root user unless told otherwise. Drives of mixed sizes are used only up to the size of the smallest drive in each group. Hot spares add to the raw capacity but not to usable space: they let a redundant array start rebuilding the moment a drive fails, and they cannot help RAID 0, which has no copy to rebuild from. Copying a full drive's worth of data takes its size divided by the transfer rate, the sum the download time calculator works out.

Frequently asked questions

How much usable space does RAID 5 give?

RAID 5 gives up one drive's worth of space to parity, so usable capacity is the number of drives minus one, times the drive size. Four 8 TB drives give 24 TB, which an operating system counting in binary units shows as 21.83 TiB before a filesystem takes its share. RAID 6 gives up two drives, so six 12 TB drives give 48 TB.

Why does ZFS show less space than RAID-Z should give?

ZFS counts space through a ratio worked out for a 128 KiB block, and on many vdev widths that block needs padding sectors on top of its parity. Each vdev is also cut down to a whole number of metaslabs, and the pool holds back a slop reserve. Six 12 TB drives in RAID-Z2 hold 48 TB of data drives in theory, but zfs list shows 43.48 TiB, which is 47.80 TB.

What is slop space in ZFS?

Slop space is a reserve ZFS keeps so that deleting files and most administrative work can still run when a pool is full. It is one thirty-second of the pool, at least 128 MiB but never more than half of it, and since OpenZFS 2.1 it is capped at 128 GiB. The metaslab each large vdev keeps for the intent log counts towards it, so the default pool here reserves 117.34 GiB.

How many drives can fail in RAID 10?

Any single drive can fail without losing data. Beyond that it depends on which drives fail: the array survives as long as no mirrored pair loses both of its drives. Eight drives can survive four failures if each one is in a different pair, but two failures in the same pair destroy the array.

Does a larger recordsize give more space on RAID-Z?

Yes, on vdev widths that need padding. Twelve 12 TB drives in one RAID-Z2 vdev hold 120 TB of data drives in theory. They store 109.56 TB with 128 KiB records, 119.14 TB with 1 MiB records and only 95.87 TB with 16 KiB records, because every block is rounded up to whole sectors and padded to a multiple of three. zfs list shows 99.62 TiB in all three cases.

Why is the usable capacity higher than zfs list shows?

zfs list charges every block at the pool's deflate ratio, which ZFS rounds down to a whole number. On a 6-wide RAID-Z2 the exact ratio would be 341.33 and ZFS uses 341, so a 128 KiB block is charged 130,944 bytes instead of 131,072. Files written in full records therefore fit about 0.1 percent more data than zfs list shows as free.

Sources

1. RAIDZ, OpenZFS Documentation
2. ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ, Matthew Ahrens, Delphix blog, now hosted by Perforce, 2014
3. module/zfs/spa_misc.c, slop space reservation, OpenZFS source code, GitHub
4. A Case for Redundant Arrays of Inexpensive Disks (RAID), UCB/CSD-87-391, EECS Department, University of California, Berkeley, 1987
5. US 4,092,732: System for recovering data stored in failed memory unit, Google Patents, 1978
6. 1988: U.C. Berkeley paper catalyses interest in RAID, Computer History Museum