Considerations when Migrating from Storage Spaces (Windows Software RAID) to ZFS Software RAID
The highlight of
Storage Spaces is the flexible use of
Hybrid Pools (HDD+Flash) via
Auto Tiering of "hot" data between the two, as well as the assignment of Spaces to either HDD or Flash. ZFS does not use this "last access" hot-tiering concept. Instead, ZFS utilizes a different tiering approach based on the
physical data type (metadata), file size, or specific settings (
small block size vs. recordsize) per ZFS dataset (filesystem or Zvol). Moving data isn't scheduled by time as in Storage Spaces, but occurs via a "ZFS rewrite" with adjusted settings. Both concepts have pros and cons. I find the ZFS approach superior because it aims to keep small, slow-access data on Flash and large, non-critical data on HDD from the start. This eliminates background re-copying (which costs time and creates load) and provides a "zero config" operation that is much simpler.
A
ZFS Hybrid Pool consists of two RAID arrays (
vdevs): one on HDD and one on Flash. If you want RAID redundancy, both must have similar reliability. The Flash array (
special vdev) should typically be between 10% and 50% of the HDD capacity, depending on how much data you want on fast Flash.
A typical pool allowing for the failure of any single drive:
- 2 x 20TB HDD Mirror
- 2 x 2TB Flash Special VDEV Mirror
- (Total Pool Capacity: 22 TB)
Only with a very high count of HDDs (e.g., 32 x HDD in multiple vdevs) you should consider a
3-way mirror for the special vdev to ensure both tiers have matching reliability. Currently, special vdevs only support mirroring; however,
RAID-Z support is planned for a future version. Both vdev types can be expanded by adding further vdevs.
Another highlight of Storage Spaces is the flexible use of a pool containing
different-sized drives, where redundancy is defined per Space rather than per Pool. Small Spaces then utilize the smaller drives. Classic RAID, like ZFS, cannot do this currently. However,
"AnyRaid" (RAID Expansion/dRAID improvements) is on the horizon. It distributes RAID across "tiles," allowing it to work with mismatched drive sizes—expected in OpenZFS 2.5 or 2.6. This is essentially an evolution of the Synology SHR concept.
Another feature of Storage Spaces is
dedup + compress (depending on the Windows version). Windows Dedup works efficiently "offline" (post-processing).
ZFS Fast Dedup is real-time deduplication and therefore requires more resources (RAM). Even with modern Fast Dedup, it should only be activated if you expect a significant deduplication ratio. However, you can now prune (shrink) and limit the size of dedup tables, as well as leverage special vdevs and ARC.
Classic ZFS Dedup should never be used due to its numerous drawbacks. For ZFS Fast Dedup, you should use the fast
BLAKE3 hash algorithm (available since Windows OpenZFS 2.4.1 rc6-1).
Windows protects
Atomic Writes (which must never be partially executed) during a crash on NTFS only when combined with hardware RAID + BBU/Flash protection.
ReFS volumes are as secure as ZFS in this regard thanks to Copy-on-Write (CoW), though they lack ZFS's broader feature set.
A further highlight of Storage Spaces is fast, flexible
virtual disks (.vhdx) that can also reside on SMB. This feature stems from Hyper-V VM management. It allows for "RAID over LAN" and replaces iSCSI (local disks from remote storage) with zero configuration effort. With
SMB Direct/RDMA, it is exceptionally fast. This also works for ZFS.
NTFS ACL permissions (a revelation if you are coming from SAMBA and Linux) work with NTFS, ReFS, and ZFS.
Miscellaneous
- L2ARC: This is a fast ZFS read cache on Flash. It has become largely obsolete with Hybrid Pools, as the latter accelerates both reads and writes.
- SLOG: (Protection for the RAM write cache) is no longer required in a Hybrid Pool starting with OpenZFS 2.4, as the log now lands on the special vdev.
- Power Loss Protection (PLP): Essential for Flash in a single SLOG setup. With a mirrored SLOG or special vdev, the risk of data loss after a power failure is low.
