This calculator sizes an Unraid cache pool from what actually fills it: the data that lives on the pool for good, the data that arrives before the Mover moves it to the array, how much each Mover run can move, and the Minimum Free Space reserve Unraid's docs describe. It warns when the Mover cannot keep up, checks your pool layout's usable space, and estimates SSD writes against the drive's rated TBW, from your own SMART readings where you have them.
A cache pool is a buffer. If each day's data is more than the Mover can move to the array in a day, the backlog grows every day and no pool size fixes it; if the Mover keeps up, the pool only needs room for the busiest stretch between runs. Sizes are decimal (1 GB is 1,000,000,000 bytes; 1 TB is 1,000 GB). Terminology follows Unraid 7.3.3 (Primary and Secondary storage, used since Unraid 6.12).
1. Data that passes through the pool
2. The Mover
3. Data that stays on the pool
Shares whose Primary storage is the pool and Secondary storage None stay on the pool; the Mover never moves them. Enter what is on the pool today, not a typical figure.
4. The pool
5. SSD writes (endurance)
Measured first: two SMART readings of the data written to one pool device, and the days between them. Leave them blank to estimate from the data above.
Rated drive writes per day:
Each Mover run can move 80 MB/s for 4 hours, 1,152 GB, against 200 GB arriving a day, so the Mover keeps up and the pool never holds more than one day's arrivals. With a largest file of 20 GB the Minimum Free Space reserve is 40 GB (double the largest file), so the pool needs 240 GB free for this traffic, plus anything that lives on it for good. Open this example
Two hours at 40 MB/s moves 288 GB a run, but 500 GB arrives each day. The Mover cannot keep up: the backlog grows by 212 GB a day, so no pool size fixes it. A longer Mover window, a faster array write or less data through the pool does. Open this example
The daily 50 GB is easy for the Mover, but the 1,000 GB import lands just after a run (the worst moment), so the pool briefly holds 1,050 GB. With the 40 GB reserve it needs 1,090 GB: more than a 1 TB mirror holds, so part of the import goes straight to the array at array speed. The burst, not the daily amount, sets the size. Open this example
SMART showed 10 TB written, then 14 TB twenty days later: 0.2 TB a day on that device, measured, so no write overhead is guessed. The Samsung 870 EVO 1 TB is rated 600 TBW; with 14 TB already written, the rest lasts about 8 years at this pace. That is when the rated writes are used up, not when the drive fails. Open this example
Required pool capacity depends on the data that lives on the pool for good, the most data that can arrive before eligible files are moved, how much the Mover can move in each run, the size of any burst, and the free space reserve. Which data is which comes from each share's settings:
| Primary storage | Secondary storage | Mover action | What happens | In this calculator |
|---|---|---|---|---|
| Pool | Array | Primary to Secondary (the default) | New files land on the pool; the Mover moves them to the array. (Unraid documentation, checked 2026-10-07) | Transient: your daily data and any peak event. |
| Pool | Array | Secondary to Primary | The Mover moves files from the array onto the pool. (Unraid documentation, checked 2026-10-07) | Resident once moved; the moves count as SSD writes ("moved back to the pool"). |
| Pool | None | None | Files stay on the pool for good, and the pool Minimum Free Space does not apply. (Unraid documentation, checked 2026-10-07) | Resident: appdata, Docker, VM disks or a pool only share. |
| Array | None | None | Files are written straight to the array. (Unraid documentation, checked 2026-10-07) | Not on the pool; see the Write Path Estimator for the array speed. |
Unraid's share placement options and their names differ between Unraid 6.12 and later and 6.11 and earlier. This page uses the names from Unraid 6.12 and later.
The buffer. Data arrives evenly between Mover runs, and a one off import lands just after a run, the worst moment (an NTK planning assumption). Each Mover run can move the array write speed times the hours it runs; with no window entered a run may continue until the next one. If a day's data is more than a day's runs can move, the backlog grows and the result says so instead of giving a size. Otherwise the most transient data on the pool at once is simulated over two weeks of runs.
The Mover's speed is the slower of the pool read and the array write. The array write is Unraid's documented typical range for the write mode, the same for any number of drives, or your measured figure. The client network is not involved: the Mover copies inside the server.
Required space = resident data + the most transient data before a Mover run + the Minimum Free Space reserve (your own setting, or double your largest file). The pool's usable space follows the layout: a mirror holds one device's worth, BTRFS RAID 1 with equal devices half the total, RAIDZ about (devices minus parity) x the smallest device. With mixed BTRFS device sizes the page points you to the BTRFS calculator Unraid links instead of guessing.
SSD writes. A SMART measurement is used as it is. Without one, the logical writes (data through the pool, app and VM writes, files moved back from the array) are multiplied by a file system write overhead, then by the share each device receives: every write for a mirror member, 2 / devices for BTRFS RAID 1 with equal devices, about 1 / (devices minus parity) for RAIDZ. The Mover reading the pool is not counted as a write. The result is the years until the rated TBW is used up, not a failure date.
| What | What NTK uses | Evidence class |
|---|---|---|
| Array write speed during a Mover run | Read/Modify/Write typically 20 to 40 MB/s, Turbo Write 40 to 120 MB/s, or your measured speed | Primary source (Unraid documentation, 2026-10-07) |
| Mover schedule | Typically at 3:40 AM; NTK starts at one run a day because Unraid states no default frequency | Primary source, NTK default (Unraid documentation, 2026-10-07) |
| Minimum Free Space | At least your largest file, preferably double, or your own setting | Primary source (Unraid documentation, 2026-10-07) |
| When the pool reaches its Minimum Free Space | New files for the share go straight to the array | Primary source (Unraid documentation, 2026-10-07) |
| Usable space and writes per device | A mirror member stores a full copy and receives every write; BTRFS RAID 1 keeps two copies; RAIDZ holds about (devices minus parity) x the smallest device | Primary sources (Unraid, OpenZFS) (Unraid documentation, 2026-10-07) (Unraid documentation, 2026-10-07) (OpenZFS, 2026-10-07) |
| Writes each RAIDZ member receives | About 1 / (devices minus parity) of large writes; small blocks add more | NTK estimate from layout geometry, Low confidence (OpenZFS, 2026-10-07) |
| How data arrives | Evenly between Mover runs; a peak event lands just after a run | NTK planning assumption |
| Extra pool writes from the file system | x 1.3 to 1.5 for large files (1.1 to 1.3 on ZFS), 1.6 to 1.8 mixed, 1.9 to 2.1 small, or your own figure; only when you have no SMART measurement | NTK planning assumption (carried over from the previous page, not measured) |
| SSD rated writes (TBW) and warranty | The vendor's datasheet figures in the table below, or yours | Vendor datasheet |
| Drive writes per day (DWPD) | TBW x 1,000 / (365 x warranty years x capacity in GB) | Derived (the definition) |
From each maker's own product page or data sheet. Rated TBW is a warranty figure. Drive writes per day spreads it over every day of the warranty. There are no prices here: check retailers for those.
| SSD | Capacity | Interface | Rated TBW | Warranty | Rated drive writes per day |
|---|---|---|---|---|---|
| Samsung 870 EVO | 1 TB | SATA | 600 | 5 years: 5 years or TBW, whichever comes first (Samsung) (Samsung) | 0.33 |
| Samsung 870 EVO | 2 TB | SATA | 1,200 | 5 years: 5 years or TBW, whichever comes first (Samsung) (Samsung) | 0.33 |
| WD Red SA500 | 1 TB | SATA | 600 | 5 years: 5 year limited warranty (the SA500 1 TB page does not state a whichever-first condition) (Western Digital (Sandisk site)) (Western Digital (Sandisk site)) | 0.33 |
| WD Red SN700 | 1 TB | NVMe | 2,000 | 5 years: 5 years or Max Endurance (TBW) limit, whichever occurs first (Western Digital (Sandisk site)) | 1.10 |
| WD Red SN700 | 2 TB | NVMe | 2,500 | 5 years: 5 years or Max Endurance (TBW) limit, whichever occurs first (Western Digital (Sandisk site)) | 0.68 |
| Kingston KC600 | 1 TB (1024 GB) | SATA | 600 | 5 years: 5 years or SSD Life Remaining (Kingston SSD Manager) (Kingston) | 0.32 |
Checked 2026-10-07. A drive's warranty term is the manufacturer's own, so check its datasheet. Your first step for a faulty product is usually the retailer that sold it. The ACCC explains your rights under the Australian Consumer Law at accc.gov.au.
Method last reviewed: 2026-10-07. Unraid, OpenZFS and SSD maker facts last checked at source: 2026-10-07. Current stable Unraid when checked: 7.3.3.
| Fact | Source | Checked |
|---|---|---|
| Shares, Primary and Secondary storage (Unraid) | ||
| Primary storage is where a share's new files are first written: a cache pool, the array, or any named pool. | Unraid documentation | 2026-10-07 |
| Secondary storage takes new files when Primary storage is below its Minimum Free Space, and is the share's final destination once the Mover runs. | Unraid documentation | 2026-10-07 |
| A share's Mover action sets the direction: Primary to Secondary, or Secondary to Primary. | Unraid documentation | 2026-10-07 |
| Unraid's share placement options and their names differ between Unraid 6.12 and later and 6.11 and earlier. | Unraid documentation | 2026-10-07 |
| Unraid 6.12.0 introduced Primary and Secondary storage: new files go to Primary, and to Secondary (if configured) once Primary is below its Minimum Free Space. | Unraid documentation | 2026-10-07 |
| With Secondary storage configured, the Mover action can be Primary to Secondary (the default) or Secondary to Primary. | Unraid documentation | 2026-10-07 |
| For a share, Unraid recommends a Minimum Free Space of twice your largest file (largest file 8 GB, set 16 GB). | Unraid documentation | 2026-10-07 |
| New user shares default to a Minimum Free Space of 10% of the disk's total capacity. | Unraid documentation | 2026-10-07 |
| The Mover (Unraid) | ||
| The Mover runs on a schedule set under Settings, Scheduler, Mover Settings; manual runs are possible but not necessary. | Unraid documentation | 2026-10-07 |
| Unraid's docs say the Mover typically moves cached data to the array at 3:40 AM. | Unraid documentation | 2026-10-07 |
| Unraid 7.2.1 added a Disable option to the Mover schedule. | Unraid documentation | 2026-10-07 |
| If files seem stuck on the pool, Unraid suggests temporarily disabling Docker and the VM Manager, then running the Mover manually. | Unraid documentation | 2026-10-07 |
| Unraid says to disable Docker and VM services before moving their files with the Mover, because open files are skipped. | Unraid documentation | 2026-10-07 |
| Data on a cache pool has no parity protection until it is moved to the array. | Unraid documentation | 2026-10-07 |
| Cache pools (Unraid) | ||
| For a cache pool, Unraid's best practice is a Minimum Free Space of at least your largest expected file, preferably double (largest 30 GB, set 60 GB). | Unraid documentation | 2026-10-07 |
| When a share's Primary storage is a pool, files go to the pool until it reaches its Minimum Free Space, then go straight to the array. | Unraid documentation | 2026-10-07 |
| For a share that uses a pool exclusively (no Secondary storage), the pool's Minimum Free Space is not applied. | Unraid documentation | 2026-10-07 |
| Unraid respects whichever floor it reaches first: the share's or the pool's Minimum Free Space. | Unraid documentation | 2026-10-07 |
| Unraid says not to set a pool's Minimum Free Space to 0, which can cause disk full errors. | Unraid documentation | 2026-10-07 |
| A share stays on the pool for good when its Primary storage is the pool and Secondary storage is None. | Unraid documentation | 2026-10-07 |
| A single device pool has no redundancy: if the device fails, data not yet moved to the array is lost. | Unraid documentation | 2026-10-07 |
| A multi device pool mirrors data across devices with BTRFS or ZFS, so it can lose one device without losing data, and devices of different sizes can be mixed. | Unraid documentation | 2026-10-07 |
| For pool capacity Unraid points to the BTRFS disk usage calculator (by RAID level and device sizes) and to its ZFS storage guide. | Unraid documentation | 2026-10-07 |
| BTRFS RAID 1 is the default for Unraid pools: it survives one disk failure at 50% space efficiency. | Unraid documentation | 2026-10-07 |
| BTRFS RAID 5 and RAID 6 are experimental; Unraid says to avoid experimental RAID levels for critical data. | Unraid documentation | 2026-10-07 |
| A new two device ZFS pool defaults to a mirror; choosing RAIDZ1 instead lets it be expanded one drive at a time later. | Unraid documentation | 2026-10-07 |
| The default file system for cache pools is BTRFS. | Unraid documentation | 2026-10-07 |
| Unraid 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time. | Unraid documentation | 2026-10-07 |
| On Unraid, adding a device to a 2 way or 3 way ZFS mirror pool makes it a 3 way or 4 way mirror. | Unraid documentation | 2026-10-07 |
| ZFS layouts (OpenZFS) | ||
| A RAIDZ group of N disks of size X with P parity disks holds approximately (N minus P) x X and survives P failed disks. | OpenZFS | 2026-10-07 |
| Attaching a disk to a ZFS mirror adds another copy (two way becomes three way); it adds redundancy, not capacity. | OpenZFS | 2026-10-07 |
| RAIDZ space efficiency depends on block size: OpenZFS's own example 3 disk RAIDZ1 stores 4K records at 50% efficiency and 128K records at about 66%; wider vdevs are more efficient. | OpenZFS | 2026-10-07 |
| Array write and drive speeds (Unraid) | ||
| Unraid's documentation gives typical array write speeds of 20 to 40 MB/s for Read/Modify/Write (the default) and 40 to 120 MB/s for Turbo Write (reconstruct write), which needs every array drive spinning and healthy. | Unraid documentation | 2026-10-07 |
| Unraid's documentation gives typical sequential speeds of 70 to 250 MB/s for a single hard drive (depending on model, age and where the data sits) and 400 to 550 MB/s for a SATA SSD. | Unraid documentation | 2026-10-07 |
| Unraid version | ||
| Latest stable Unraid OS release is 7.3.3 (docs release notes: 7.3.3 dated 2026-10-08). | Unraid documentation | 2026-10-12 |
| Unraid 7.4.0 is still a release candidate (7.4.0-rc.1, 2026-10-08), so 7.3.3 remains the current stable release (unraid_evidence current_version). | Unraid documentation | 2026-10-12 |
The calculator models Unraid's own Mover schedule. Community plugins can change when the Mover runs; they are not part of Unraid, and NTK does not model them.
Mover Tuning is a third party plugin first posted by Squid (shown as Administrators on the forum) on 8 April 2018; scheduled moves can be skipped until the cache passes a selectable fill threshold. The post states no fill percentage.
Mover Tuning's own first post says its default settings leave the Mover working as Unraid normally does.
The Mover Tuning thread was active when checked: its last page (144 of 144) has posts from 29 September 2026 about a beta build, installed from a community GitHub repository (masterwishx/ca.mover.tuning).
Support thread: Unraid forums.
Ask us anything about NAS, storage, or infrastructure. We reply by email.
Message sent!
We'll be in touch soon.