Review TrueNAS metadata VDEV redundancy before adding a fusion pool

Bottom line: Treat the metadata VDEV as a pool-layout decision with a failure-tolerance and removal review. Do not approve the addition solely because a proposed device is fast or has spare capacity.

Source fact: what the authority says

The TrueNAS Fusion Pools guide says the special allocation class stores metadata, indirect blocks and deduplication tables, with optional small-file blocks. It warns that losing a special VDEV without redundancy corrupts the pool and prevents access to its data. The guide recommends special-VDEV failure tolerance equal to or greater than the data VDEVs’ tolerance. It says a whole metadata VDEV can be removed only when the data VDEVs are mirrors; with RAIDZ data VDEVs, that addition is permanent.

What the source does not establish

This article addresses the versioned special-VDEV layout decision, not a device qualification or performance guarantee. Whole-VDEV removal is the scope of the permanence statement; this article does not prescribe a drive-replacement or member-detachment procedure.

Applicability questions

• Are the pool’s data VDEVs mirrors, RAIDZ or another separately reviewed topology?
• What failure tolerance is required from the metadata allocation class?
• Which exact devices and redundancy layout are proposed?
• Does the owner accept the documented whole-VDEV removal boundary?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a before-and-proposed pool diagram that labels data VDEVs and the special allocation class separately. Have a second storage administrator reconcile the diagram with actual pool status. Resolve any uncertainty about existing topology before ordering or assigning the additional devices.

Compare the proposed special-VDEV redundancy with the failure tolerance of the data VDEVs. Write the owner’s accepted failure scenario in plain language, including what simultaneous device loss the design is intended to tolerate. Keep hardware compatibility and endurance assessment in the applicable device review rather than inferring suitability from the allocation-class name.

For a proposed RAIDZ data pool, make the documented permanent-addition boundary an explicit approval item. Do not offer later whole-VDEV removal as an easy rollback. For a mirrored-data design, review the supported removal procedure separately before promising it as a recovery option.

Use a disposable representative pool for any proposed layout exercise. Keep production backup and recovery evidence available through the established storage process. Leave performance claims open until a separately designed workload comparison has been completed under approved conditions.

Verification and evidence

Proposed verification: inspect the disposable pool’s data topology and selected special-VDEV members against the approved diagram. Record the reported redundancy and device identities. Ask another reviewer to identify which whole-VDEV removal branch the topology permits from the cited documentation.

Where an expressly approved failure or recovery exercise is required, follow its separately reviewed procedure and retain actual pool and harmless-file observations. Do not create a destructive production failure to demonstrate the warning. Preserve the final pool diagram and the owner’s acceptance of permanence and recovery requirements.

Official references

• TrueNAS — Fusion Pools — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.