ZFS Capacity Calculator

A ZFS pool is built from vdevs, and a RAIDZ vdev is ZFS’s version of RAID 5, 6 or 7 with one, two or three disks of parity. The number on the drives’ labels is never the number you get to use. The page walks from raw capacity to a realistic planning figure so you can size a pool before buying disks.

The steps from raw to usable

Raw capacity is the number of disks times their size across all vdevs. Parity takes one disk’s worth of space per vdev for RAIDZ1, two for RAIDZ2 and three for RAIDZ3, leaving the capacity after parity. ZFS then reserves slop space, 1/32 of the pool by default, so that a full pool can still delete files and commit changes. What is left is the approximate usable space. The page also reports it in TiB because ZFS tools use powers of 1024, and drives are sold in decimal TB.

The 80 percent guideline

ZFS is a copy-on-write file system and needs free blocks to write into. As a pool fills, free space becomes fragmented and performance falls, so many administrators plan to stay below about 80 percent. The page therefore shows a “comfortable fill level” at 80 percent of the usable figure, which is the number to use when promising capacity to users. It is guidance rather than a limit: a pool of mostly large, sequentially written files tolerates more.

Entering a design

Choose the RAIDZ level, the number of disks per vdev, the disk size in TB and the number of vdevs. Presets load six 10 TB disks in RAIDZ2, two vdevs of eight 16 TB disks in RAIDZ2, and four 4 TB disks in RAIDZ1. A pool made of several vdevs multiplies the parity cost, because every vdev pays it, so two small vdevs yield less space than one wide one built from the same disks, in exchange for more parallelism.

A worked example

Six 10 TB disks in one RAIDZ2 vdev give 60.00 TB raw. Two disks go to parity, which leaves 40.00 TB. The slop reserve takes 1/32 of that, 1.25 TB, so the approximate usable space is 38.75 TB (35.24 TiB). A comfortable fill level at 80 percent is 31.00 TB, and the efficiency is 65 % of raw. A pool of those disks that is nearly full would be both slow and uncomfortably close to the reserve.

Limits

Real pools are slightly smaller again because of block padding on small records and metadata. Compression and deduplication can make stored data larger than the pool, and special vdevs, hot spares and cache devices are not counted. RAIDZ expansion and different record sizes change the behaviour too. Treat the page as a planning tool and use zpool list and zfs list on the real system. For classic RAID levels use the RAID Calculator.

Choosing a layout

Capacity is only one input to the design. A RAIDZ vdev delivers roughly the random I/O of a single disk, so a pool of one wide vdev is good for streaming large files and poor for many small random reads. Mirrors give far better random performance and grow by adding pairs, at the cost of half the raw space. Larger drives take longer to resilver, which is a reason to prefer RAIDZ2 over RAIDZ1 for big disks. Enter a few candidate layouts into the calculator, compare the usable figures, and then weigh them against how the pool will be used.

Related tools

• RAID Calculator compares traditional RAID levels.
• CCTV Storage Calculator estimates the data a recording pool must hold.
• Byte Converter converts between TB and TiB.
• Server Rack Planner checks that the storage chassis fits the rack and power plan.