Skip to main content

Storage Parameters

Usable Capacity

12 TB

Fault Tolerance

4

Array Resilience

Architecture

RAID 5 • Parity

Fault Tolerance

1 Concurrent Failures Allowed

Current Configuration

RAID 5 (Parity)

12 TB Usable

Total RAW: 16 TB

Disk 01DATA
Disk 02DATA
Disk 03DATA
Disk 04PARITY

Total Drives

4 x 4 TB

Efficiency

75% Utilized

Usable: 12 TBWasted to redundancy: 4 TB

Pros & Cons

  • PRO: Good balance of capacity/speed/safety

  • PRO: Cost-effective redundancy

  • CON: Slower writes due to parity calculation

    This setup prioritizes redundancy but has associated performance or capacity costs.

Guide

Windows Storage Spaces

Everything you need to know about Microsoft's software-defined storage layer — layouts, performance, caveats, and how it stacks up against ZFS, mdadm, and hardware RAID.

IntermediateWindows 10/11 Pro & ServerLast updated June 2026

What is Windows Storage Spaces?

Windows Storage Spaces is Microsoft's software-defined storage technology built directly into Windows 10/11 Pro, Enterprise, and Windows Server (2012 R2 and later). It lets you pool physical disks into a virtual storage pool and then create virtual disks from that pool with configurable resiliency — think of it as a RAID controller that lives entirely in software, managed through the Windows Storage Management API.

Storage Spaces operates at the block layer. You present raw disks (SATA, SAS, NVMe) to the operating system, group them into a storage pool, carve out one or morevirtual disks (called "spaces"), and then format those with NTFS or ReFS. Each virtual disk gets its own resiliency type, column count, and tiering policy independent of other virtual disks in the same pool.

Because it's integrated into Windows, Storage Spaces requires no kernel drivers, no third-party software, and no hardware RAID controller. Any disk the OS sees is a candidate — including USB drives (though you shouldn't use those for anything serious). Management is available through the Server Manager GUI, the Settings app on Windows 10/11, and the fullStorage Spaces PowerShell module.

Key fact

Storage Spaces is not the same as Storage Spaces Direct (S2D). Spaces is single-host, shared-nothing storage. S2D is the hyper-converged, multi-node version for Windows Server Datacenter with RDMA, NVMe tiering, and cluster-aware resiliency.

Storage Layouts — The RAID Equivalents

Storage Spaces offers three resiliency types. Choosing the right one is the most important decision you'll make, because you generally cannot change it after creation without rebuilding the virtual disk.

Simple (no resiliency)

RAID equivalent: RAID 0

Min drives: 1

Data is striped across all disks with no parity or mirror. Maximum capacity and performance, zero fault tolerance. Lose any one disk and the entire virtual disk is gone. Useful only for scratch space, temp files, or workloads where you already have redundancy at a higher layer.

Mirror

RAID equivalent: RAID 1 / RAID 10

Min drives: 2

Data is written to multiple copies (two-way or three-way mirror). Two-way mirror needs at least 2 disks (like RAID 1 on a pair, or RAID 10 across more). Three-way mirror needs 5+ disks. Excellent read performance, good write performance, and N-1 (or N-2) disk fault tolerance.

Parity

RAID equivalent: RAID 5 / RAID 6

Min drives: 3

Single parity (RAID 5 equivalent) needs 3+ disks. Dual parity (RAID 6 equivalent) needs 7+ disks. Provides better capacity efficiency than mirroring, but write performance is severely degraded — especially on consumer hardware without a battery-backed or dedicated write-back cache.

Performance summary

Mirror performs well for most workloads (near line-rate on modern SSDs). Parity, by contrast, is notorious for terrible write performance — expect 40–100 MB/s writes even on fast hardware. Microsoft recommends parity only for cold data or archive workloads. Always benchmark your specific layout before committing production data.

Key Differentiators from Traditional RAID

Thin Provisioning

When you create a virtual disk, you specify a size that can be larger than the physical capacity of the pool. Storage Spaces only consumes space as data is actually written. This lets you over-commit capacity across multiple virtual disks — but you must monitor pool usage carefully, because writes will fail when the pool fills up.

Resiliency Per Virtual Disk

A single pool can host multiple virtual disks, each with a different layout. You could have a mirror-backed OS volume and a parity-backed archive volume living on the same set of physical disks. Traditional RAID controllers typically apply one RAID level per logical drive group.

Storage Tiers (SSD + HDD Auto-Tiering)

Windows Server and Windows 10/11 Pro can combine SSDs and HDDs into a single pool and create a tiered virtual disk. Frequently accessed ("hot") data is automatically migrated to the SSD tier, while cold data lives on the HDD tier. Tiering operates in 1 MB chunks and runs as a background optimisation task. The feature works best with at least one SSD per HDD in the pool.

Column Count — The Most Confusing Concept

A column is one data stripe written across one physical disk. The column count determines how many disks participate in a single write operation — and it directly determines fault tolerance.

Example — 4-disk pool, two-way mirror:

  • Column count = 1: Each write goes to 1 data + 1 copy, both on the same disk group. You can lose 1 disk but only if the data is on the surviving copy.
  • Column count = 2: Data is striped across 2 disks with 2 mirror copies. You need at least 4 disks. One disk per column can fail.
  • Column count = N: Powershell's New-VirtualDisk -NumberOfColumns N. Higher column count = more parallelism but more disks needed for the same fault tolerance.

Rule of thumb: leave the column count at Auto unless you deeply understand the trade-offs.

Performance — What to Expect

Storage Spaces performance varies wildly depending on the layout, number of disks, and whether you're using consumer or enterprise hardware.

Mirror Performance

Two-way and three-way mirrors perform very well. Reads can be served from any copy, so read throughput scales roughly linearly with the number of mirror copies. Write throughput is bounded by the slowest disk in the column — but on all-SSD pools, expect hundreds of thousands of IOPS. This is the layout most homelab users should choose.

Parity Performance

This is the elephant in the room. Storage Spaces parity on consumer hardware is agonisingly slow for writes — typically 40–120 MB/s sequential, and often single-digit MB/s for small random writes. The root cause is that Storage Spaces does not implement an on-disk write-back cache on consumer editions. Every parity write is a read-modify-write cycle: read old data, read old parity, compute new parity, write data, write parity. Without a fast log device or battery-backed cache, the latency penalty is unavoidable.

On Windows Server with dedicated write-back cache (a journal on a fast SSD or NVMe), parity performance improves dramatically — but that requires specific hardware and software configuration.

Heads-up

If you are building a NAS with Windows and expecting RAID 5 / RAID 6 write speeds from a hardware controller, Storage Spaces parity will disappoint you. In most homelab scenarios, two-way mirror with a small SSD tier delivers a far better performance/capacity trade-off.

Column Count & Performance

Increasing the column count spreads data across more physical disks, which improves sequential throughput (more spindles in parallel). However, it also reduces fault tolerance per column and increases the number of disks that must participate in a single write. For parity spaces specifically, higher column counts make the already expensive parity computation even more punishing.

Comparison: Storage Spaces vs. ZFS, mdadm, Hardware RAID

FeatureStorage SpacesZFSmdadmHW RAID
Checksums / bitrot protection No Yes (core feature) No No
Thin provisioning Yes Yes (sparse vols) No No
Auto-tiering (SSD+HDD) Yes Yes (special vdev) Manual Vendor-dep.
Parity write performance Poor (consumer) Good (with SLOG) Good Excellent (w/ cache)
Recover without OS Hard (Windows only) zpool import mdadm --assemble Same controller
Snapshots VSS / ReFS only Built-in, instant LVM layer No
Compression No Yes (LZ4 et al.) No No
Mix drive sizes Yes Limited (vdev-wide) Yes (min size) No (same size)
License cost Windows license Free (OpenZFS) Free (Linux) $$ (HBA + cache)

Storage Spaces Direct (S2D) — The Server Edition

Storage Spaces Direct (S2D) is Microsoft's hyper-converged storage solution for Windows Server Datacenter (2016 and later). It turns a cluster of servers into a single, distributed storage fabric using RDMA (Remote Direct Memory Access) networking. Unlike the single-host Storage Spaces described above, S2D is a full-scale-out SAN replacement.

Key S2D Features

RDMA Networking

S2D uses RDMA (RoCE or iWARP) to move data between cluster nodes at wire speed without CPU involvement. 25 GbE or faster is standard. The cluster sees all disks on all nodes as a single pool.

NVMe + SSD + HDD Tiers

S2D supports three storage tiers — NVMe, SSD, and HDD — with automatic caching. Fast devices cache reads and writes for slower devices. The cache behaviour is configurable (read-only, write-through, write-back).

Cluster-Aware Resiliency

Unlike single-host Storage Spaces, S2D can survive node failures. A three-way mirror in a 4-node cluster can lose up to 2 nodes and still serve data. The data placement logic is aware of the cluster topology.

Scale-Out File Server (SOFS)

Virtual disks created via S2D are presented as SMB3 shares. Hyper-V VMs, SQL Server, and other workloads access storage over the network with multi-channel SMB for throughput and failover.

Important

Storage Spaces Direct requires Windows Server Datacenter edition — it is not available on Windows 10/11, Windows Server Standard, or any consumer SKU. It also requires certified hardware (Azure Stack HCI catalog) for production use.

Use Cases — Where Storage Spaces Shines (and Where It Doesn't)

Great For

  • Windows Server labs and test environments — spin up a pool with spare disks and experiment with layouts.
  • Backup targets — mirror-backed spaces for Veeam or Windows Server Backup repositories, especially with deduplication enabled on top.
  • Cold / archive storage — parity spaces are acceptable for write-once-read-maybe workloads where capacity efficiency matters more than speed.
  • Media storage pools — large mirror or simple spaces for Plex / Jellyfin libraries where data is replaceable.

Not Recommended For

  • High-performance VM storage — if you need hundreds of thousands of random IOPS with low latency, go with ZFS (with SLOG/L2ARC) or a hardware RAID + flash array.
  • Primary storage without a backup strategy — no checksums means silent corruption can go undetected. Always pair with regular integrity checks or ReFS.
  • Cross-platform pools — a Storage Spaces pool can only be read by Windows. Recovery on Linux requires low-level disk parsing and is not straightforward.
  • Write-heavy parity workloads — database logs, VM live migration, or any workload with sustained writes will bring parity spaces to their knees.

Limitations You Need to Know

No Data Checksums

Storage Spaces does not implement end-to-end data checksums at the virtual-disk layer. Silent corruption (bitrot) can occur and go undetected until an application reads bad data or a file hash check fails. If you format the virtual disk with ReFS, you get some integrity-checking at the filesystem level, but it's not as comprehensive as ZFS's checksum-everything approach.

Parity Write Performance

As discussed above, parity performance on consumer Windows editions is abysmal. Microsoft's own documentation recommends parity only for archival data. There is no built-in write-back cache, no SLOG-like device, and no way to accelerate parity writes without moving to Windows Server + dedicated SSD journal.

Hard to Recover Without Windows

Storage Spaces stores pool metadata in a proprietary format on each disk. If your Windows installation is corrupted and you cannot boot, recovering the pool requires another Windows system. There are no open-source tools (like zpool import for ZFS ormdadm --assemblefor Linux MD) that can parse Storage Spaces metadata. A Windows repair disc or a second Windows install is your only recovery path.

GUI vs. PowerShell Management

The Settings app GUI on Windows 10/11 is extremely limited — you can create simple spaces but cannot configure column count, tiering, or advanced options. For anything beyond a basic two-way mirror, you must use PowerShell:New-VirtualDisk -FriendlyName "Data" -StoragePoolFriendlyName "Pool1" -ResiliencySettingName Mirror -Size 2TB -NumberOfColumns 2PowerShell gives you full control, but the learning curve is steep.

Pro Tips

Always leave one free drive slot

Storage Spaces does not handle a completely full pool gracefully. If you run out of physical space, all writes to all virtual disks fail — even to thin-provisioned volumes that still have logical space. Reserve a drive bay for emergency expansion or replacement.

Column count determines fault tolerance

The single most misunderstood concept. Increasing the column count does NOT increase redundancy — it changes how data is laid out across disks. A 4-disk, 2-column, two-way mirror can lose 1 disk per column (2 total). A 4-disk, 4-column, two-way mirror can lose only 1 disk total. Always understand the column-to-disk relationship before creating a space.

Benchmark before committing data

Use diskspd.exe orfio on Windows to test your space's I/O characteristics. A few minutes of benchmarking can save you months of regret if you pick the wrong layout.

Format with ReFS for integrity

Although ReFS is not as robust as ZFS, it provides file-level checksums and integrity streams that catch bitrot on Storage Spaces volumes. Combined with a mirror layout, this gives you a surprisingly solid data-integrity story on Windows.

Use fixed provisioning for VMs

Thin provisioning is convenient, but for Hyper-V or VMware VM storage, use fixed (thick) provisioning. Thin-provisioned spaces can suffer from fragmentation and unpredictable performance under contention. Fixed provisioning allocates space immediately and avoids these issues.

Keep the pool simple

One pool = one set of disks. Adding and removing disks from a pool is possible but cumbersome. Plan your disk count and layout up front. You can expand a pool by adding new disks, but you cannot shrink a pool without destroying and recreating virtual disks.

Frequently Asked Questions

Is Storage Spaces as good as ZFS?

Not for data integrity and feature depth. ZFS has end-to-end checksums, instantaneous snapshots, built-in compression, deduplication, and a mature ecosystem. Storage Spaces is easier to set up for Windows users and integrates natively, but it lacks ZFS's data-protection guarantees and performance under parity workloads. If you want the most resilient storage possible, ZFS wins. If you need a simple mirror pool on Windows without learning a new OS, Storage Spaces is fine.

Why is Storage Spaces parity so slow?

Storage Spaces implements parity using a read-modify-write cycle: every small write must read the old data and old parity, compute the new parity, then write both data and parity. Consumer Windows editions have no write-back cache to buffer these operations. The result is abysmal write throughput (40–120 MB/s sequential, often single-digit MB/s random). Additionally, parity computation is CPU-bound and Storage Spaces does not use GPUs or offload engines. If you need parity performance, use dedicated hardware RAID, ZFS with a SLOG, or Windows Server with a write-back cache journal.

Can I mix drive sizes in Storage Spaces?

Yes — and this is one of Storage Spaces' best features. Unlike hardware RAID (which requires identical disks) or ZFS (which is constrained by the smallest disk in a vdev), Storage Spaces pools can contain any mix of sizes, speeds, and interfaces. Each disk contributes its full capacity to the pool. However, space is allocated proportionally: a 4 TB disk will contribute roughly twice the usable capacity of a 2 TB disk in the same pool. This flexibility is a major advantage for homelab users who accumulate disks over time.

How do I recover a Storage Spaces pool?

Recovery requires a functioning Windows installation (or Windows PE / Recovery Environment). Connect all pool disks to the system, open Server Manager or PowerShell, and the pool should appear automatically. If it doesn't, run `Get-StoragePool -IsPrimordial $false` in PowerShell to discover pools. There are no third-party recovery tools that can reliably parse Storage Spaces metadata. The metadata format is proprietary and changes between Windows versions. Always maintain a current backup — do not rely on the pool being recoverable.

Is Storage Spaces Direct available on Windows 10/11?

No. Storage Spaces Direct (S2D) requires Windows Server Datacenter edition (2016 or later). It is not available on Windows 10/11 Pro, Enterprise, or Windows Server Standard. The single-host Storage Spaces that ships with Windows 10/11 Pro is a completely different product under the hood. Do not believe forum posts claiming you can enable S2D on Windows 10 — those are describing the regular (non-Direct) Storage Spaces feature.

stashraid.io / guides / windows-storage-spaces-guide

All trademarks and product names belong to their respective owners. This guide is for educational purposes. Always verify configuration against Microsoft's official documentation.