What is a ZFS VDEV?
What Is a VDEV in ZFS?
A ZFS VDEV is a virtual device that provides storage to a ZFS pool. A VDEV can be constructed from one drive or multiple drives arranged as mirrors or RAIDZ groups. One or more VDEVs are then combined to create the overall zpool.
VDEV layout is important because redundancy exists primarily within each VDEV. The failure tolerance of the entire pool therefore depends heavily on the design of every VDEV that contributes storage to it.
Drives → VDEVs → Zpool
Understanding this hierarchy is one of the most important steps in understanding ZFS storage design.
Physical Drives
HDDs, SSDs or other supported block-storage devices provide the physical capacity.
VDEVs
Drives are grouped into VDEVs with a specific redundancy layout such as a mirror or RAIDZ.
Zpool
One or more VDEVs contribute capacity and performance to the ZFS storage pool.
What Types of ZFS VDEVs Are Common?
The VDEV layout determines how data and redundancy are distributed across the drives contained within that VDEV.
Single-Disk VDEV
A VDEV can consist of one storage device. By itself, this layout does not provide redundancy against failure of that device.
ZFS Mirror
Multiple devices hold redundant copies of data. Mirrored VDEVs are commonly used where redundancy and strong random I/O performance are priorities.
ZFS Mirror Guide →RAIDZ1
RAIDZ1 uses single parity and can tolerate one device failure within that RAIDZ1 VDEV.
RAIDZ1 Guide →RAIDZ2
RAIDZ2 uses double parity and can tolerate two device failures within that RAIDZ2 VDEV.
RAIDZ2 Guide →RAIDZ3
RAIDZ3 uses triple parity and can tolerate three device failures within that RAIDZ3 VDEV.
RAIDZ3 Guide →Redundancy Exists Inside the VDEV
One of the most important ZFS design principles is that drive-failure protection is determined by the redundancy of the individual VDEV. Adding multiple VDEVs to a pool does not automatically make a non-redundant VDEV redundant.
If a top-level VDEV is lost beyond its redundancy tolerance, the storage pool can be lost because the pool depends on all of its top-level data VDEVs.
Example: Two Mirrored VDEVs in One Zpool
Drive A + Drive B
Two drives store redundant copies within the first VDEV.
Drive C + Drive D
Two additional drives create a second mirrored VDEV.
Why Use Multiple VDEVs?
A zpool can contain multiple top-level data VDEVs. Adding appropriate VDEVs increases the pool's available capacity and can also increase aggregate I/O capability because ZFS can distribute data across the pool's VDEVs.
How VDEV Layout Affects Usable Capacity
| VDEV Type | Redundancy | Capacity Cost | General Characteristic |
|---|---|---|---|
| Single Device | None | No redundancy overhead | Maximum raw capacity, no device-failure protection |
| Mirror | Redundant copies | Capacity used for mirrored copies | Strong redundancy and useful I/O characteristics |
| RAIDZ1 | Single parity | Equivalent capacity affected by one parity level | Higher usable capacity than equivalent-width higher-parity RAIDZ layouts |
| RAIDZ2 | Double parity | Equivalent capacity affected by two parity levels | Greater fault tolerance than RAIDZ1 |
| RAIDZ3 | Triple parity | Equivalent capacity affected by three parity levels | Highest parity protection of the three RAIDZ levels |
Actual usable ZFS capacity also depends on drive sizes, filesystem overhead, pool allocation, metadata and other configuration factors.
Should Drives in a VDEV Be the Same Size?
Using drives with similar capacity and performance characteristics is generally the cleanest approach when designing data VDEVs.
In many redundant configurations, usable capacity is constrained by the smallest device in the VDEV. Mixing very different drive sizes can therefore leave part of the larger drives unavailable for ordinary VDEV capacity.
VDEV Design Affects ZFS Performance
Capacity is not the only reason to think carefully about VDEV layout. Different VDEV designs provide different performance characteristics.
Mirror VDEVs or RAIDZ VDEVs?
There is no single VDEV layout that is best for every ZFS deployment. Mirrors and RAIDZ make different tradeoffs between usable capacity, redundancy, I/O behavior, drive count and expansion strategy.
Performance & Flexibility
Commonly considered where random I/O, resilver behavior and incremental expansion using additional mirror VDEVs are important design considerations.
Capacity & Parity Protection
Commonly considered where capacity efficiency and parity-based redundancy across larger groups of drives are important.
What Happens If a VDEV Fails?
A degraded VDEV can continue operating while its configured redundancy remains intact. For example, RAIDZ2 can tolerate up to two failed devices within that RAIDZ2 VDEV.
If failures exceed the VDEV's redundancy and the top-level VDEV can no longer provide its data, the consequences can extend to the entire pool. This is why VDEV layout should be designed before the pool is placed into production.
VDEVs and ZFS Resilvering
When a failed or replaced device belongs to a redundant VDEV, ZFS may need to reconstruct the required data onto the replacement device. This process is called resilvering.
Questions to Ask Before Choosing a VDEV Layout
Compare RAIDZ Redundancy Levels
RAIDZ1 vs RAIDZ2
Compare single-parity and double-parity VDEVs for capacity and fault tolerance.
View Comparison →RAIDZ2 vs RAIDZ3
Compare double-parity and triple-parity VDEVs for higher levels of drive-failure protection.
View Comparison →Redundant VDEVs Are Not Backups
A mirrored or RAIDZ VDEV can protect against specified device failures, but redundancy does not protect against every cause of data loss. Accidental deletion, malicious changes, software problems, catastrophic hardware loss and other events can still affect the storage pool.
ZFS VDEV FAQ
What does VDEV mean in ZFS?
VDEV means virtual device. It is a storage building block that contributes capacity to a ZFS pool.
Is a VDEV the same as a zpool?
No. A zpool contains one or more VDEVs. The VDEVs provide the physical storage capacity used by the pool.
Can a VDEV contain one drive?
Yes. A single storage device can be used as a VDEV, although a single-device data VDEV does not provide redundancy against failure of that drive.
Can a zpool contain multiple VDEVs?
Yes. ZFS pools can contain multiple top-level data VDEVs that contribute capacity and I/O resources.
Is RAIDZ a VDEV?
RAIDZ1, RAIDZ2 and RAIDZ3 are common layouts used for ZFS data VDEVs.
Is a ZFS mirror a VDEV?
Yes. Multiple drives can be grouped into a mirrored VDEV that stores redundant copies of the data.
What happens if one VDEV fails?
If failures exceed the redundancy available within a top-level data VDEV, the entire pool can be affected because the pool depends on all of its data VDEVs.
Can VDEVs use different drive sizes?
They can, but usable capacity in many redundant VDEV layouts is constrained by the smallest participating drive, so similar capacities are usually preferable.
Are more VDEVs faster?
Additional data VDEVs can increase aggregate I/O opportunities, but actual performance depends on workload, VDEV type, drives and the complete system.
Which VDEV layout is best?
There is no universal best layout. Capacity, fault tolerance, workload, performance, drive count and future expansion requirements should guide the design.