This commit adds support for AnyRAID VDEVs.

Overview

OpenZFS introduces Anyraid, a new virtual device (VDEV) type that allows disks of different capacities to be combined into a single top-level VDEV while maintaining redundancy.

Unlike traditional RAID configurations, Anyraid dynamically distributes storage across disks using fixed-size allocation units called tiles.

1. How Anyraid Works

• Mixed disk sizes: Combines drives of different capacities without restricting every drive to the smallest disk’s capacity.
• Tile-based allocation: Divides physical disks into equally sized tiles.
• Tile size: The larger of 16 GiB or 1/64 of the smallest disk’s capacity at creation.
• Dynamic allocation: Selects the nparity + 1 disks with the most unallocated tiles when additional storage is needed.
• Redundancy: Combines tiles from separate disks into logical mirrored groups.

Currently, Anyraid supports mirror-style redundancy only. RAIDZ-style parity is planned.

2. Metadata and Reliability

Anyraid requires a mapping between logical storage addresses and physical tiles.

• Stores the tile map in reserved regions at the beginning of each disk.
• Maintains four rotating copies of the mapping metadata.
• Replicates all four copies across every disk.
• Allows the mapping to be recovered from a surviving disk’s metadata.

This avoids a bootstrap dependency on the ZFS Meta Object Set (MOS).

3. Capacity and Scalability

Property	Limit
Maximum disks	256 theoretical
Maximum tiles per disk	65,536
Maximum tiles per VDEV	16,777,216
Metadata map size	64 MiB per copy
Maximum disk-size ratio for full utilization	1024:1

The capacity limits result from the fixed-size tile mapping structure.

4. Supported Operations

Anyraid supports several existing ZFS operations:

• Scrubbing and resilvering
• Device replacement and removal
• Adding new disks to expand storage
• Allocating new tiles on newly added disks
• Debugging tile placement through enhanced zdb functionality

Important: Adding drives expands available capacity, but existing tiles are not automatically redistributed.

5. Current Limitations and Future Plans

Feature	Status
Mixed-capacity disks	Supported
Mirror-style redundancy	Supported
RAIDZ-style parity	Planned
Online capacity expansion	Supported
Automatic tile rebalancing	Planned
VDEV contraction	Planned
Scrubbing and resilvering	Supported

The lack of automatic rebalancing means that adding a disk does not immediately redistribute existing data or equalize disk utilization.

6. Implementation Scope

The commit includes:

• 116 modified files
• 5,432 additions and 446 deletions
• New Anyraid VDEV implementation
• Changes to ZFS allocation, metadata handling, and pool management
• Additional functional tests and ztest coverage

Development was sponsored by Eshtek (HexOS) and Klara, Inc. GitHub

7. Practical Implications for TrueNAS

Anyraid could eventually make ZFS storage expansion more flexible, particularly for home servers and NAS systems with mixed-capacity drives.

For example, users could potentially combine 4 TB, 8 TB, and 12 TB disks in one redundant VDEV instead of constructing separate VDEVs with matching drive sizes.

However, this commit alone does not establish that Anyraid is available in a stable OpenZFS or TrueNAS release.

Anyraid represents a significant architectural change for OpenZFS, enabling flexible, redundant storage across differently sized disks.

Its main advantages are better utilization of mixed-capacity drives and easier expansion. Its key remaining limitations are mirror-only redundancy, no automatic tile rebalancing, and no VDEV contraction.

For production NAS deployments, release integration, stability testing, and support for the planned features remain important considerations.

https://github.com/openzfs/zfs/commit/816804dfdddd4d2159d8370c99cd4db09e39f9b2