Independent Australian Storage & Infrastructure Authority

Unraid Write Path Estimator: Normal vs Turbo Write

This Unraid write path estimator explains what happens to a file when it's written to your Unraid array, based on your drive count, drive type, controller, write source and turbo write setting. Clarifies cache bypass, mover behaviour, and when turbo write is safe to use.

Turbo Write (formerly called Reconstruct Write) sounds like a free speed upgrade, but it's not always faster, and it comes with trade-offs. Whether it helps you depends on how many drives you have, what you're writing, and whether your drives are already spinning.

This tool estimates real-world write speeds for both modes under your setup, and tells you plainly when Turbo Write is worth enabling.

Important: You generally won't see better than a single drive's sequential write speed writing to the array: Normal Write is often far below it. Turbo Write can get much closer in the right setup, but results depend on drive count, the slowest disk, and your controller. This tool shows speeds as absolute ranges for both modes.

Your Array Setup

Write source mainly affects write pattern (sequential vs random, sustained vs bursty). Turbo Write helps most with sustained sequential writes regardless of source.

Normal Write
—
Drives active
—
Est. power
—
Best for
—
Turbo Write
—
Drives active
—
Est. power
—
Best for
—
Controller may be a bottleneck
Mover and Turbo Write Turbo Write can speed up Mover writes when moving large sequential files and when most drives are already spinning. If the mover job would spin up the whole array for every run, the extra power and noise may outweigh the benefit. If your array is already active when the mover runs, Turbo Write may still help. Consider the CA Auto Turbo Write Mode plugin for automatic switching based on drive spin state.
Slowest disk limits Turbo Write throughput
SMR drives and Turbo Write SMR drives perform poorly under the sustained write patterns Turbo Write generates. If you have SMR drives in your array, Turbo Write may cause write stalls rather than speed improvements. CMR drives are strongly recommended for Unraid data and parity disks.
Local/VM writes and Turbo Write Container and VM disk writes are typically random and bursty, not sustained sequential. Turbo Write's reconstruction overhead is optimised for large sequential transfers, so it usually gives little or no benefit for this write pattern, the speeds above assume a sequential workload. Store VM images and container appdata on a cache pool (SSD) instead of the parity-protected array where possible.
SSD/NVMe in the main array Unraid documents SSDs in the main parity array as unsupported/experimental: TRIM/Discard isn't available there and performance can degrade over time the way it doesn't on a cache pool. "SSD/NVMe mix" also isn't one performance class, SATA SSD and NVMe sequential speeds can differ by several times, and this estimator assumes every drive matches a single selected type. Treat these numbers as a rough ceiling, not a guarantee, and consider whether an SSD cache pool fits your use case better than an all-SSD array.

Single-drive speed: You generally won't see better than a single drive's sequential write speed writing to the array: Normal Write is often far below it, and Turbo Write can get much closer in the right setup. The comparison here is Normal Write vs Turbo Write under your specific configuration.

Normal Write (Read-Modify-Write) is constrained by platter rotation: after reading old data and parity and calculating new parity, the drive must wait for the write position to rotate back around. This rotation penalty significantly reduces throughput, commonly observed at 20-40 MB/s for sustained array writes on 7200 RPM HDDs.

Turbo Write (Reconstruct Write) eliminates the rotation wait by writing data immediately and reconstructing parity in parallel from all other drives. Typically 1.5-4x faster than Normal Write for sustained large sequential writes depending on drive count, and can get closer to single-drive speed in larger arrays with fast CMR drives, though results still depend on the slowest participating disk and controller/bus limits.

Auto Turbo Mode: Unraid has announced a future built-in Auto write mode option, but it has not shipped yet. Until then, the CA Auto Turbo Write Mode plugin (Community Applications) provides equivalent automatic switching today, based on how many drives are currently spinning. This is the recommended approach for most users.

Further reading: Unraid array write modes, official docs (Read/Modify/Write vs Turbo Write/Reconstruct Write).

Speed ranges reflect typical real-world throughput reported by the Unraid community for each drive count and class, and assume every drive in the array matches the selected drive type: a mixed-speed array is bottlenecked by its single slowest participating disk, which this estimator cannot model without knowing every drive's type. File size modifiers account for the overhead of small-file operations under both write paths. Controller caps reflect real bandwidth constraints on shared-bus onboard SATA implementations, though at the speeds this estimator produces a budget controller is unlikely to be the binding constraint; the on-page warning is informational, not a modelled cap.

Power draw is estimated using typical active read/write wattage per drive class (7200 RPM HDD: ~9 W, 5400 RPM: ~4.5 W, SSD/NVMe: ~3 W), plus a lower idle-wattage figure for drives that are already spinning but not part of the current write's active drive set. Spun-down and mixed-state drives are assumed to draw ~0 W when idle; standby draw and spin-up energy aren't modelled. AU electricity rate used: $0.30/kWh.

Last reviewed: 4 September 2026

Frequently Asked Questions

Turbo Write writes new data immediately, then reads all other data drives simultaneously to reconstruct parity. It is typically 1.5-4x faster than Normal Write for sustained large sequential writes, depending on drive count and configuration. Normal Write is often far below single-drive speed; Turbo Write can get much closer in larger arrays with the right setup. The cache pool bypasses parity overhead entirely for initial writes.
Writing to the array always involves parity. Normal Write reads old data and parity before writing (rotation penalty). Turbo Write reads all drives to reconstruct parity after writing (reconstruction overhead). The cache pool bypasses this for initial writes, if raw write speed matters, writing to cache first is the right approach. The array write speed is the speed after the Mover has moved data from cache to the parity-protected array.
The CA Auto Turbo Write Mode plugin (Community Applications) automatically switches between Normal and Turbo Write based on how many drives are currently spinning. When most drives are already active, it switches to Turbo Write to maximise throughput. When drives are spun down, it stays on Normal Write to avoid the spin-up cost. Unraid has announced a future built-in Auto write mode option, but it has not shipped yet, so the CA plugin is currently the way to get this behaviour. This is the recommended approach for most users.
No. Parity integrity is maintained in both modes: Turbo Write just uses a different calculation path to the same parity result. Your array is no less protected with Turbo Write enabled. During a drive failure, parity will correctly reconstruct missing data regardless of which write mode was used.
It depends on your usage pattern. If Turbo Write causes all drives to spin up for every small write, more spin cycles accumulate over time, and drive spin-up is one of the higher-wear events in a HDD's life. For users who write infrequently or have a mostly idle array, Normal Write is kinder to drives. For arrays in continuous heavy use where drives are always spinning, the difference is negligible.
Yes. Settings → Disk Settings. Changes take effect on the next write operation. No array stop is required. This makes it easy to test both modes and observe the difference in your own dashboard.
Possibly, but more likely culprits are drives spinning up from a stopped state (the first write after idle will be slow regardless of mode), the cache pool filling up (writes bypass the parity array until then), or a single slow drive acting as a bottleneck. Check per-drive activity in the Unraid dashboard during a sustained transfer to diagnose. Also confirm whether your writes are going to cache or directly to the array.
Rarely. Container and VM writes are typically random and bursty: Turbo Write's reconstruction overhead costs outweigh its benefits for these workloads. The recommendation is to store VM images and container appdata on a cache pool (SSD) rather than the parity-protected array. Array storage is best used for large media files and backups where sequential throughput matters.

AU Cache SSD Pricing: Enabling Turbo Write

Turbo Write (Reconstruct Write) reads all data drives simultaneously, which requires all drives to be spinning. A cache pool doesn't make Turbo Write itself faster: writes that land on cache bypass the array's Normal/Turbo write path entirely (they're cache writes, not array writes). What a cache pool gets you is avoiding the array's parity overhead for the initial write; when the Mover later copies cache contents to the array, array disks still spin up and the Normal/Turbo choice above still applies to that move. For most home NAS users, a cache pool sized for your working set is still the most effective way to get fast initial writes. Cache SSD prices from Mwave, PLE, Amazon AU.

DriveCapacityAU retail rangeBest for
Samsung 870 EVO500 GB$349-$384Small cache pool: SOHO or home with light writes
Samsung 870 EVO1 TB$496-$569Standard home cache, most 4-bay Unraid builds
WD Red SN700 NVMe1 TB$500-$560High-throughput writes, media ingest, VM workloads
WD Red SN700 NVMe2 TB$590-$650Large active dataset, production media library

Normal vs Turbo Write: AU Home NAS Decision Summary

For a typical AU home Unraid build with 4-6 data drives in an energy-saving spin-down config, Normal Write is usually the better default. Turbo Write shines when your workload keeps drives spinning anyway, use this estimator to check whether your scenario actually benefits.

Related Tools