When you import a pool, ZFS reads the vdev labels, and each label carries its own uberblock ring. The ZIL doesn't get replayed until later, when the datasets mount, and only on a writable pool.
Missing SLOG vdev
A dedicated NVMe or SSD log device disappears. ZFS refuses to import without confirmation. The actual data loss is bounded: only sync writes since the last txg commit.
Uberblock Corruption
The rotating uberblock ring on every vdev label points to past transaction groups. At import, ZFS skips any uberblock that fails verification and uses the valid one with the highest txg. If the pool won't import from that one, it needs a rewind to an older txg.
Vdev Label Damage
Each member keeps four copies of its label, L0/L1 at the front of the drive and L2/L3 at the back.
Slow DDT Load After Import
This one doesn't stop the import. Holding the dedup table in ARC takes roughly 1 to 5 GB of RAM per 1 TB of deduplicated data. The table is read on demand from disk, so an undersized host still imports the pool. Loading it on demand can take days.
dRAID Vdev Topology
dRAID is a distributed-parity vdev type that arrived in OpenZFS 2.1. Its layout is declustered, which means data, parity, and spare capacity are permuted across every member. You set the topology when you create the pool, with a vdev spec string:
draid2:4d:11c:1s
# parity = 2 redundancy level per redundancy group (1, 2, or 3)
# 4d = 4 data devices per redundancy group
# 11c = 11 total member devices in the vdev
# 1s = 1 distributed spare (sliced across all children, not a whole drive)
The vdev label on each member doesn't store that string. The geometry sits in separate integer fields instead. OpenZFS writes several of them, including nparity, draid_ndata, draid_nspares and draid_ngroups.
The distributed spare is spare capacity that's allocated ahead of time, then sliced and interleaved across all the children in the same permutation. That spare isn't a drive sitting idle as a dedicated hot-spare.
When a member fails, the sequential resilver writes the reconstructed data into those distributed-spare positions across the surviving drives, not onto one separate replacement disk. That's why a dRAID resilver restores redundancy faster than a RAIDZ healing resilver. It's a fixed-width sequential rebuild that reads from all children at once.
Fault tolerance is still the parity level and nothing more. A draid2 vdev survives two lost members; lose a third before the resilver finishes and the vdev FAULTS and the pool goes offline, same math as raidz2.
We image every member through a write-blocker and read the dRAID geometry fields off the labels. The declustered layout takes the same enterprise TrueNAS handling covered on our TrueNAS server recovery workflow.
