Skip to main content
TRUENAS & NAS

TrueNAS and ZFS: Pools, Vdevs, RAIDZ and Dataset Design

Separate usable capacity from raw disks; plan mirror/RAIDZ topology, dataset boundaries, snapshot growth and expansion together.

Content update:

Architecture and operating model

Physical devices form vdevs; top-level data vdevs form a ZFS pool. Datasets represent filesystem boundaries and zvols block devices. Dataset quotas do not create independent physical failure domains. Losing a top-level data vdev can lose the pool, so assess redundancy in each vdev topology.

Choose mirrors or RAIDZ from random I/O, concurrency, rebuild time and accepted failure patterns alongside capacity. RAIDZ1/2/3 have different parity levels, not unlimited pool-wide tolerance. Multiple failed disks in mirrored vdevs may be survivable only when distributed across different mirrors. Allow for additional faults and load during large-disk resilvering.

Account separately for TB/TiB conversion, parity, metadata, allocation, snapshot-retained blocks and free-space headroom. Snapshot growth depends on changed blocks and retention. Measure compression using representative data; do not budget deduplication as guaranteed savings. Dedup adds memory, metadata and operational costs.

Use department, application or lifecycle boundaries for datasets. Evaluate quotas, reservations, compression, recordsize, ACLs and snapshot policies per workload. Reservations can set aside capacity before consumption; quotas cap usage. Changing recordsize does not rewrite every existing block. Measure application I/O and consistency rather than copying arbitrary tuning values.

Expansion depends on version, OpenZFS features and vdev type. Adding a vdev, replacing disks with larger ones and supported RAIDZ expansion are different operations with different distribution/performance effects. A special vdev can hold critical pool data, unlike disposable cache. Record backup, compatibility and rollback boundaries for every change.

  1. 1Measure data and churn
  2. 2Design vdevs and datasets
  3. 3Estimate capacity and failures
  4. 4Pilot and growth plan
Calculate capacity against topology and data lifecycle.

Design parameters

Vdev failure boundary
Assess redundancy per vdev and failure distribution.
Net capacity
Allow parity, snapshots, metadata and growth headroom.
Dataset policy
Bind quotas/reservations and ACL/retention to workloads.
Expansion method
Plan version/topology-compatible operations with independent backup.

Worked example

For six 8 TB disks in illustrative RAIDZ2, the simple parity estimate is (6−2) × 8 = 32 TB nominal data space, not actual usable capacity. Convert to roughly 29.1 TiB, then allow metadata, allocation and headroom. An illustrative 20% reserve leaves about 23.3 TiB; this percentage is an assumption, not a universal rule.

At 100 GiB of unique changed blocks daily and 14-day retention, an initial snapshot allowance is 1,400 GiB. Repeated blocks and compression change actual usage; refine using dataset measurements. Budget live data, snapshots and growth before setting quotas and alerts.

Troubleshooting

ObservationLikely cause / distinctionVerification
Pool has space but a dataset cannot writeQuotas, refquotas or reservations may constrain writes.Inspect pool and dataset space separately.
Deleting a snapshot frees little spaceOther snapshots/clones may still reference blocks.Check references and actual allocated space.
More disks did not improve performanceVdev layout or another bottleneck may dominate.Map IOPS, latency and queues to topology.

Acceptance checks

  1. Calculate capacity against topology and data lifecycle.
  2. Record each vdev failure boundary.
  3. State TB and TiB explicitly.
  4. Measure snapshot growth from actual churn.
  5. Distinguish quotas from reservations.
  6. Verify independent backup before expansion.

Related concepts

Capacity and usable headroom

Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.

Filesystem and storage layers

An application directory, mount point, logical volume and physical device belong to different layers. Inode exhaustion, read-only mounts and filesystem errors can stop writes even when space appears available. A snapshot often shares the same storage failure domain and is not an independent backup. Mount options and expansion methods depend on the filesystem. Verify mounts after reboot: writing to an unmounted directory can fill the wrong device.

IOPS and block size

IOPS measures operations per second, whereas MB/s measures transferred data. Identical IOPS values produce very different bandwidth at different block sizes. For example, 10,000 operations/s at 4 KiB is approximately 39.1 MiB/s. Read/write mix, random versus sequential access and protection mechanisms affect the result. Measure actual block distributions and concurrency rather than transferring a benchmark result directly to production. High disk IOPS does not prove good application response; latency must be examined alongside it.

Latency distribution

Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.

Retention and capacity

Retention defines which recovery points are kept and for how long. Daily, weekly and monthly points do not represent identical change patterns; full-copy creation and chain dependencies affect physical capacity. Retention decisions combine business requirements, applicable obligations and technical capacity. Longer retention does not automatically provide better recovery: the right point must be discoverable and readable. When changing a policy, test whether existing points are deleted immediately or handled differently by the product.

Availability versus recovery

High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.

Primary documentation

Editorial method

Prepared by the Doz Technology technical team using official vendor documentation. Scenarios and calculations illustrate the method; they are not completed customer tests. Before implementation, verify versions, licences, client support, security conditions and rollback in your environment. Select solutions against existing products and workload requirements.

Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!