Learn NAS - Hardware & Storage Planning

#Introduction

A reliable NAS starts with well-planned hardware. Episode 3 focuses on hardware and storage planning: choosing the right CPU and RAM, understanding why ECC RAM matters for ZFS, picking an HBA and NIC, and designing a disk layout that balances capacity, drive bays, budget, and reliability.

Many beginners make the mistake of buying the cheapest disks without calculating their needs. Yet hardware decisions set the maximum performance, capacity, and data safety ceiling of your NAS for years to come.

By the end of this episode you'll be able to put together a NAS specification list that fits your needs, from a budget NAS to a production-grade build with 10GbE and ECC.

#Core Components: CPU, RAM, and Motherboard

#CPU

The CPU for a NAS doesn't need to be the most expensive, but it must be sufficient for your workload. For basic file sharing, an entry-level CPU with a few cores is enough. If you plan to run apps, VMs, or ZFS encryption, choose a CPU with more cores and virtualization support.

Note also that native ZFS encryption and zstd compression can take advantage of modern instruction sets. A recent-generation CPU will make these operations much faster without burdening the system.

#RAM and ZFS Requirements

ZFS is a hungry consumer of RAM, and that's intentional: ARC (Adaptive Replacement Cache) uses free RAM to speed up access to frequently used data. As a rule of thumb, provide at least 1 GB of RAM per terabyte of raw storage, plus room for the system and applications.

Equally important: ECC RAM. Because ZFS relies on checksums to detect data corruption, non-ECC RAM that silently corrupts data in memory can render checksums useless. For important data, use a motherboard and CPU that support ECC.

dmidecode -t memory | grep -E "Error Correction Type|Maximum Capacity"

If the output shows Multi-bit ECC, your system supports memory error correction. That's a big plus for ZFS.

#Storage Controllers: HBA and Passthrough

#Choosing the Right HBA

An HBA (Host Bus Adapter) is a card that connects many disks to the system, usually based on an LSI/Broadcom chipset in IT mode. Avoid RAID cards in hardware RAID mode: for ZFS, disks must be accessed raw so that ZFS manages redundancy itself.

lspci | grep -i "sas\|raid"
lsblk

The lspci command shows the SAS/RAID controller installed. Make sure the controller runs in IT mode (passthrough), not RAID mode.

#Passthrough in Virtualization

If the NAS runs as a VM, consider PCIe passthrough of the HBA to the VM so ZFS gets direct access to the disks without a virtualization layer. This avoids SMART and snapshot compatibility issues. On Proxmox or ESXi, passthrough is done by mapping the HBA's PCI device to the VM.

#Networking: NIC and 10GbE

#Choosing a NIC

The NIC (Network Interface Card) determines your NAS's transfer speed. For basic needs, 1GbE is enough for media streaming and ordinary file sharing. If your workload involves video editing, large backups, or many users, consider 10GbE, which is 10 times faster.

Also pay attention to port count: a NIC with two or more ports enables bonding/LAG in episode 8 for bandwidth aggregation and link redundancy.

ethtool eth0

The Speed value in the ethtool output shows the actual link speed, for example 10000Mb/s for 10GbE.

#SSD Caches: SLOG, L2ARC, and Special VDEV

#SLOG for Sync Writes

SLOG (Separate Intent Log) is a dedicated SSD device that captures synchronous write operations so ZFS can acknowledge them as quickly as possible. SLOG is not a read-write cache; it's an intent log recorder that makes sync writes much faster. Use an SSD with power-loss protection and good fdatasync support.

#L2ARC for Reads

L2ARC is a second-level read cache that lives on SSD or NVMe. Unlike ARC, which uses RAM, L2ARC can be much larger. Use it only if there's identified hot data, because L2ARC still consumes RAM for its index metadata.

#Special VDEV

A Special VDEV stores metadata and small blocks so operations like file creation and directory listing become very fast, while the main HDDs focus on large data. This is an advanced topic we'll break down in episode 17.

#Disk Layout and Budget

#Designing the Array Topology

Once the core components are decided, design your disk layout according to the number of available bays:

• Mirror: two disks, one copy of data for one disk; simple, fast rebuild.
• RAIDZ1: three or more disks, survives one disk failure, capacity-efficient.
• RAIDZ2: four or more disks, survives two disk failures, well suited for large capacity.

Don't forget to provide a hot-spare and consider the budget: larger disks are cheaper per terabyte but lengthen rebuild times. For production NAS setups, prioritize RAIDZ2 or double mirror over saving one disk.

lsblk -o NAME,SIZE,MODEL

Use the lsblk output to map the actual capacity of each disk before making topology decisions.

#Closing

In this episode 3 you planned NAS hardware comprehensively: CPU and RAM with ECC considerations for ZFS, an IT-mode HBA with passthrough, NICs up to 10GbE, SLOG and L2ARC cache options, and a disk layout balancing budget and reliability.

Key takeaways:

• ZFS uses RAM for ARC; provide at least 1 GB per terabyte of raw storage.
• ECC RAM is strongly recommended for ZFS so checksums stay meaningful.
• Use an IT-mode HBA so disks are accessed raw, not through hardware RAID.
• SLOG speeds up sync writes; L2ARC speeds up reads; both are optional.
• RAIDZ2 or double mirror are the safe choices for important data.

In the next episode, episode 4, we'll perform the installation and initial configuration of TrueNAS SCALE and OpenMediaVault — from installing the ISO and boot environments to setting up the first storage pools and network through the Web UI. Your hardware is planned; now it's time to set it up.