Data recovery and complex ZFS layout features
The three more complex ZFS layout features are (in order of implementation in ZFS):
- dRAID
- RAIDZ Expansion
- AnyRaid
Data recovery for each of these comes with its own associated costs.
These costs come in two parts:
-
The cost of layout detection -
first we need to know how many vdevs there are,
how many drives in each, how many parities, what the positions of the disks are, and such like.
-
The cost of reads -
the additional work we need to do for every read given the specific layout.
On a simple vdev, there is nothing. Read the data, see if the checksum matches or not, and declare either success or failure.
On a mirror, if checksum fails, try the other copy.
On a RAIDZ1, there are various parity reconstructions.
RAIDZ2 requires more parity reconstructions, RAIDZ3 requires even more, and so on.
dRAID
dRAID is a set of layouts (with one, two, or three parities)
designed for a single vdev with very many drives.
It can have integrated spares - when there is no dedicated spare disk, but spare blocks are
scattered across the entire disk set.
The goal is to allow for fast sequential parity rebuilds,
reducing the rebuild time and thus the window of vulnerability during disk replacement.
dRAID recovery should be relatively easy to implement.
Not trivial, but relatively easy.
The layout detection is simple and there is no additional penalty
associated with reads once the layout is detected.
It is just another layer of instantaneous address translation.
The only real reason it is not already in is that I don't see any demand for it.
As I understand the practice, dRAID is used for very wide arrays,
and with very wide arrays one typically gets proper admins and proper backups.
RAIDZ expansion
Single and mirror vdev expansion is trivial,
implemented in ZFS for ages, and does not require any special handling.
RAIDZ expansion is more complicated.
The expansion requires rewriting the entire vdev and keeping track of all the previous vdev layouts.
Recovery of expanded RAIDZ volumes is already implemented in Klennet Recovery (as of May 2026, build 3349).
It does add complexity to both layout detection and reads, resulting in, say, 50% increase in recovery time.
The details are covered in dedicated article if you are interested.
AnyRaid
AnyRaid works to allow mixing-and-matching drives on different sizes in a single vdev.
It works (similar to MS Storage Spaces) by splitting each disk into small "tiles", then allocating
the "tiles" as required, spreading the data so as to fill the disks proportionally to their size.
ZFS AnyRaid is not finalized yet (as of May 2026), and there is nothing practical to work with.
Once it is ready for the public release, I expect an influx of broken pools.
Everyone is going to throw all sorts of dubious hardware tougher,
producing configurations unreliable beyond description, and these are going to start crashing shortly thereafter.
The recovery from that is going to be interesting, too.
Good thing they want it for mirrors first.
In summary
- dRAID - if you need to recover a dRAID disk set for real, put in a support request.
- Expanded RAIDZ - recoverable with Klennet Recovery build 3349 and up.
- AnyRaid - not implemented in ZFS yet, so nothing to see here so far.
Filed under: ZFS.
Created Thursday, May 14, 2026