ZFS RAIDZ2 Calculator for NAS Capacity

The hardware is exciting, the home server project begins, and then you see the math, and that’s when things get interesting. Eight twenty-two-terabyte drives sound like a hundred seventy-six terabytes of storage when you buy them. However, capacity shrinks when you make the pool. Parity consumes two drive, metadata claims another, and converting from decimal terabytes to binary tebibits removes even more. It is not a scam; it is simply price of reliability.

The confidence provided by RAIDZ2 allows you to yank two drives without skipping a beat and continue on your merry way, because sometimes a drive fails while you’re running a scrub, and sometimes a power surge drops a second disk in the same vdev. That peace of mind come at a cost, expressed in terms of capacity and planning.

How to Calculate Your Real Storage Space

No need to do any mental calculations; the calculator (above) runs it for you. But it’s still good to know how it works under the hood.

First, remember that manufacturers sells their drives in decimal, meaning a “twelve terabyte” drive is actualy around ten point nine tebibytes. You immediately lose almost nine percent on that conversion alone. Next, remember that you need two extra parity drives for RAIDZ2, reducing your pool by those two drives. With a six-drive pool, that leaves four data drive’s worth of capacity. And if you have a hot spare, that is another drive used only for extra space when it is not needed. The tool factors all this in and provides a reserve for ZFS metadata, which is necessary since snapshots and small files fragment space more rapidy than you’d think.

The biggest single design decision is selecting the correct vdev width. For most home labs, six to ten drives per vdev is the sweet spot. Wider vdevs is less efficient. They also take longer to resilver if a drive fails. This is risky because the pool stays down until the rebuild finishes. Twelve-wide is more efficient but requires more work from your remaining drive during rebuild. Wide vdevs are fine if you’ve got a media server that just sits there. But if you’re running active backups or virtual machines, keep the vdevs narrow to lessen the stress on the rebuild process. The calculator shows you how this tradeoff works out: how much slower rebuild time vs it shows how much extra space you’ll gain.

The other thing: Don’t skip the fill target value. In fact, that breathing room is what helps ZFS perform best. Twenty percent free is not simply good advice from operating system folks. It’s good practice for a healthy file system. Too little breathing room will cause write amplification to spike. Snapshots will take up additional space. Performance will suffer from fragmentation. The calculator takes into account your fill target and adjusts your usable capacity to match. This gives you an idea of what really fits and helps you not hit the ceiling.

You also should consider turning on compression, especially if you’re going to be storing encrypted media. And if you have databases or log files, you’ll see higher ratios like one point five, meaning, you get more capacity with less hardware.

What about drive choice? It’s important. Shingled Magnetic Recording drives (which excel at sequential writes) should not be used in a RAIDZ array as they will choke when asked to perform the random writes that a resilver requires. You’ll be without any protection of your data while waiting days for the rebuild to complete. Standard consumer grade CMR drives remain standard for good reasons, they’re cheap, reliable, and fast enough for home usage. Depending on your configuration, the calculator shows power estimates by drive type. This helps you verify your power supply headroom if you’re looking to build something larger, such as a rack unit.

A lot of folks will throw one more disk at an already-existing vdev and then call it a day. Don’t be like those folks. You can only add complete vdevs when growing ZFS; you can’t just add a disk here and there. So if you begin with a 6-disk vdev, the next time you want to expand you’ll have to make another 6-disk vdev. This way you don’t end up with weird things down the road (the table on the page makes it clear).

Remember, every disk you purchase needs to do some work for the team. Don’t optimize storage to fill each and every byte. Storage optimization is an exercise in finding balance between performance, safety and cost. A solid starting point is RAIDZ2, provided that you understand the overhead it imposes on you. Know what to expect from compression. Plan your vdevs with care. Provide breathing room for growth. Once you get the picture, the math is easy. You would of seen better results from your data if you are disciplined.