Unraid Array vs Pool: Parity, Speed and Best Uses

Unraid looks like a NAS distribution and behaves like one, but its storage model is unusual enough that assumptions carried over from RAID lead people astray. The differences are worth understanding before committing disks to it.

The array is not RAID

In a conventional striped array, a file is broken into chunks spread across every member disk. Unraid does not do this. Each data disk in the array holds an independent filesystem, and each file is written whole onto one disk. The array presents a unified view across those disks, but underneath, any single disk can be removed and read on another machine as an ordinary filesystem.

Two consequences follow. First, read and write throughput for a single file is limited to the speed of one disk, because only one disk is involved. Second, a failure that exceeds what parity can rebuild costs you the contents of the failed disks only, not the entire array. Everything on the surviving disks remains intact and readable.

That second property is the reason many people choose Unraid for bulk storage. It trades peak performance for a much gentler failure mode. It is also the clearest dividing line against a striped ZFS pool or a vendor appliance, which is worked through in Unraid vs TrueNAS vs Synology.

Parity is calculated, not copied

A parity disk holds no files. It holds the computed parity of every corresponding position across the data disks, which is what allows a missing disk to be reconstructed. Because parity must cover the largest possible offset on any data disk, the parity disk must be at least as large as the largest data disk in the array. Adding a data disk bigger than the current parity disk means replacing parity first.

A single parity disk lets the array survive one failed disk. Adding a second parity disk lets it survive two simultaneously. Parity is also why writes to the array are slower than writes to a bare disk: each write has to read the old data, read the old parity and write both back unless a write method that trusts parity is in use.

Because parity sizing is fixed at purchase time rather than adjustable later, it is the first decision in the Unraid hardware guide, and the parity calculator will model usable capacity and rebuild time for a specific drive mix.

Parity is not a backup. It protects against a disk dying. It does not protect against deletion, corruption written through the array, or a failure that takes out more disks than parity covers. What that protection looks like on the day it is needed, including why a disk marked with a red X is often a cable fault rather than a dead drive, is covered in Unraid disk disabled.

Cache pools absorb the write penalty

A cache pool is one or more disks sitting outside the parity protected array. Writes land there at full speed, and a scheduled mover process migrates them to the array later. This is what makes large transfers feel fast despite the parity write cost.

A single disk cache pool has no redundancy. Anything written to it and not yet moved is lost if that disk dies. If the pool holds data that never moves, which is the normal arrangement for application data, redundancy inside the pool matters.

Where application data belongs

Docker containers and virtual machines generate constant small random writes. Running them against the parity array is slow and keeps disks spinning. The standard arrangement is to keep the container application data share and virtual machine images on a cache pool, with the mover configured to leave them there rather than migrating them to the array.

How files are placed on disks

Because each file lands whole on one disk, something has to choose which disk. That is the share’s allocation method, and the choice changes how the array fills and how often drives spin up.

• High-water, the default, fills disks progressively using switch points derived from half the capacity of the largest drive. It keeps usage roughly level across the array while keeping related files together and minimizing spin-ups, which is why the manual points it at media servers and at arrays built from mixed drive sizes.
• Most-free selects the disk with the most free space for each new file. Capacity is used efficiently, but disks are switched constantly and more of them stay awake. The documented fit is high-throughput work such as video editing.
• Fill-up writes to disks in numeric order until each one reaches the minimum free space threshold, then moves on to the next. The manual lists both minimum free space and split level as required configuration for it, and puts it forward for static archives.

Minimum free space is the amount that has to remain on a drive for it to stay eligible for new writes, and the manual’s rule of thumb is twice the size of the largest file you expect to write. It is the setting that exists to prevent disk-full errors under fill-up, so a value set too low is how a transfer runs out of room on the disk it started on while the array as a whole still reports free space.

Split levels decide when a folder may span disks

Allocation picks a disk. Split level decides whether a file is allowed to go to a different disk from its siblings in the first place, and it overrides the allocation method when the two disagree. Four settings are available.

• Automatically split any directory, the default, creates whatever folders are needed on the selected disk regardless of folder depth.
• Automatically split only top level creates first-level subfolders on a disk only when they do not already exist there.
• Automatically split top N levels hands the levels you name to Unraid and leaves anything deeper on the same disk as its parent.
• Manual places new files and folders only on disks where the parent directory already exists.

The practical consequence is about blast radius rather than capacity. A restrictive split level keeps a series, a photo year or a backup set together on one disk, so a failure beyond what parity covers costs that whole folder and nothing else. A permissive split level spreads the same folder across the array, which uses space more evenly and leaves the folder partially recoverable instead. Neither is wrong; the point is to pick deliberately rather than inherit the default.

Primary, secondary and the mover schedule

A share’s storage is configured as two tiers. Primary storage is where new writes land, and secondary storage takes the overflow once primary falls below its minimum free space threshold. With a pool as primary, files go to the pool until it reaches minimum free space and then go straight to the array. Where a share and a pool both define a floor, the manual says Unraid respects whichever one it reaches first.

The mover is what shifts data between the two tiers on a schedule. Mover action sets the direction: cache to array is the normal arrangement for bulk shares, while array to cache is the reverse, used to pull a share back onto fast storage after maintenance. The schedule itself lives under Settings, User Preferences, Scheduler, the same page that governs parity check frequency and SSD TRIM, and the array manual notes the mover typically runs at 3:40 AM by default.

Two operational points follow from that. Shares holding container application data and virtual machine images are the case for leaving the mover pointed away from them, because migrating files that are rewritten constantly gains nothing. And the manual is explicit that Docker and VM services should be disabled before running the mover against files they hold open, since open files are skipped rather than moved.

Common mistakes

• Sizing parity below a data disk you intend to buy later, which forces a parity replacement before the disk can be added.
• Leaving application data on a single unprotected cache disk, where nothing is standing behind the drive.
• Assuming array read throughput scales with disk count. One file, one disk.
• Treating parity as a substitute for an off machine backup of the data you cannot recreate.
• Leaving minimum free space at a value smaller than the files being written, so writes fail on a disk while the array still reports capacity.
• Filling the array to the point where new writes have nowhere to land within the configured allocation and split rules.