TrueNAS Zvol vs Dataset: When to Use Each (2026)

On TrueNAS, a dataset is a ZFS filesystem for sharing files (SMB, NFS, app storage), while a zvol is a raw virtual block device for a single consumer (an iSCSI target or a VM disk). Use a dataset when you are sharing files, which covers most home NAS use; use a zvol only when something needs a raw, unformatted disk it formats and owns itself.

When you carve up a ZFS pool on TrueNAS, you create one of these two things inside it. The zvol vs dataset decision (or dataset vs zvol, whichever way you search for it) sounds interchangeable, and the UI presents them side by side, but they are fundamentally different objects, and choosing wrong means either awkward sharing or poor performance. This guide explains the difference and gives you a clear rule for each common use case.

Dataset vs zvol: the core difference

A dataset is a filesystem. It holds files and folders, it’s what you point SMB and NFS shares at, and ZFS manages the files inside it — permissions, snapshots, compression, and concurrent access by multiple clients. When you want “a place to store and share files,” you want a dataset. Datasets are also how you organize a pool: you nest them to apply different settings (compression, snapshot schedules, quotas) to different kinds of data.

A zvol is a virtual block device. It presents as a raw, unformatted disk. ZFS doesn’t manage files inside it — something else formats it (NTFS, ext4, VMFS) and owns the filesystem. A zvol is what you export over iSCSI, or hand to a VM as a virtual disk. It’s by definition meant for a single consumer that treats it like a local drive.

A useful mental model: a dataset is a shared folder TrueNAS manages; a zvol is a disk TrueNAS lends out and the client manages.

Zvol vs dataset: quick comparison

Attribute	Dataset	Zvol
Type	ZFS filesystem (files and folders)	Virtual block device (raw disk)
Best use case	SMB/NFS shares, app data, general file storage	iSCSI targets, VM disks, single-consumer block
Snapshots	Yes — browsable via .zfs/snapshot	Yes — opaque block image (clone or roll back)
Share protocols	SMB, NFS (file-level)	iSCSI (block-level), direct VM attach
Tuning knob	recordsize — dynamic ceiling, default 128K	volblocksize — fixed at creation, default 16K
Overhead	Low; flexible record sizing	Write amplification if volblocksize is mismatched

Which should you use?

• Sharing files with multiple devices (SMB/NFS)? Create a dataset.
• Storing TrueNAS SCALE app or container data? Create a dataset.
• Exporting iSCSI block storage? Create a zvol.
• Giving a VM a raw block device? Create a zvol.
• Not sure? Create a dataset — it is the right answer for the overwhelming majority of home NAS use. If you are still setting the system up, start with How to set up TrueNAS SCALE.

TrueNAS record size: recordsize vs volblocksize

TrueNAS record size is set differently for each object, and mixing the two up hurts performance. The record-size knob on a dataset is recordsize; the equivalent on a zvol is volblocksize. This is the parallel that confuses people, and it matters for performance.

• Datasets have a recordsize — the maximum logical block size, default 128K. It’s dynamic: ZFS uses up to recordsize but writes smaller records for smaller files. Because it’s a ceiling, the default is fine for most file workloads, and you only raise it (e.g., 1M) for large sequential media or lower it for specific small-random workloads.
• Zvols have a volblocksize — the block size of the virtual device, which on current TrueNAS defaults to 16K. Unlike recordsize, volblocksize is fixed and chosen at creation; it does not adapt. You match it to the consumer’s I/O pattern up front: smaller (8-16K) for database/VM random I/O, larger for sequential. You cannot change volblocksize later without destroying and recreating the zvol — so decide before you write data.

The headline: volblocksize is to a zvol what recordsize is to a dataset, but recordsize is a flexible ceiling while volblocksize is a hard, permanent choice.

Defaults and when to change them

Object	Setting	Default	Change later?	When to tune
Dataset	recordsize	128K	Yes (affects new writes only)	Raise toward 1M for large sequential media; lower to 16-32K for database files
Zvol	volblocksize	16K	No (fixed at creation)	Set up front: 4-16K for VM/database random I/O, larger for sequential streams

Sane defaults work for most people: leave a dataset at the 128K record size and a zvol at 16K unless a specific workload says otherwise. Because volblocksize cannot be changed after the zvol exists, it is the one worth deciding in advance. For the full picture on how record size interacts with ARC caching and compression, see ZFS performance tuning: ARC and recordsize.

When to use a dataset

Create a dataset when:

• You’re setting up an SMB or NFS share — file sharing always points at a dataset. See SMB shares setup.
• You’re storing app/container data on TrueNAS SCALE — create per-app datasets so backup and snapshots are clean (covered in the SCALE apps guide).
• You want to organize the pool and apply different compression, quotas, or snapshot policies to different data types.
• You’re storing VM disk files (qcow2/raw on a filesystem) and want them visible and snapshottable at the file level — many homelabs prefer this over zvols for simplicity.

Datasets are the default answer for the overwhelming majority of home NAS use. If you’re not sure, you almost certainly want a dataset.

When to use a zvol

Create a zvol when:

• You’re exporting iSCSI block storage — an iSCSI target is backed by a zvol. See iSCSI vs NFS vs SMB.
• A VM needs a raw block device rather than a disk file (some hypervisor setups, or when you want the VM to own the filesystem directly).
• An application specifically wants raw, unformatted block storage.

Zvols are the specialist tool: block storage for a single consumer. Reach for one only when something genuinely needs a disk rather than a folder.

A common mistake

Don’t create a zvol because you “want a disk for backups” and then struggle to share it — a zvol exported over iSCSI is single-client and the client owns the filesystem, so it’s the wrong tool for multi-device file storage. If several machines need to drop backups onto the NAS, that’s a dataset with an SMB/NFS share. Conversely, don’t try to put a VM’s raw block disk on an SMB share and wonder about performance — block workloads want a zvol (or at least a tuned dataset holding disk files).

Another: leaving a zvol’s volblocksize at default when hosting a database with a known page size. Because it’s fixed at creation, mismatched volblocksize causes read/write amplification you can’t fix without rebuilding the zvol. Decide the block size against the workload first.

Snapshots, compression, and replication on both

Both datasets and zvols are first-class ZFS objects, so the core ZFS features work on either:

• Snapshots work on both. A dataset snapshot captures the filesystem; a zvol snapshot captures the block device’s bytes. The difference is browsability: you can open a dataset snapshot’s files directly (via the hidden .zfs/snapshot directory or the UI), whereas a zvol snapshot is an opaque block image you must clone or roll back to use.
• Compression (LZ4 by default) and encryption apply to both.
• Replication with zfs send/zfs receive works on both and is the basis of TrueNAS replication tasks, so you can back up an iSCSI zvol to another box exactly as you would a dataset. See the snapshot and replication strategy guide for setting this up.

The practical implication: choosing a zvol does not cost you ZFS data integrity or backup capability. What it costs you is multi-client file sharing and easy browsing, which is the whole reason datasets exist.

Can you convert a dataset to a zvol (or back)?

There is no in-place conversion. A dataset and a zvol store data in fundamentally different layouts, so “switching” means creating the new object and copying data across:

• Dataset to zvol: create the zvol with the right volblocksize, then copy data at the file level into whatever filesystem you put on the zvol (you cannot cp a folder tree directly onto a raw block device).
• Zvol to dataset: mount or attach the zvol, then copy its files out onto the dataset.

Because volblocksize is permanent, getting the zvol sizing right up front (see above) matters even more when you realize the only fix is a full rebuild. If you are still deciding how the underlying pool should be laid out, the RAIDZ vs mirrors guide covers the vdev topology that both objects sit on top of.

Quick reference

Use case	Create a…	Notes
SMB / NFS file share	Dataset	Default for file sharing
TrueNAS SCALE app data	Dataset	One per app for clean backups
VM disk as a file (qcow2/raw)	Dataset	Simpler, file-level snapshots
iSCSI target	Zvol	Set volblocksize for the workload
VM raw block device	Zvol	Single consumer owns the FS
Database needing raw block	Zvol	Match volblocksize to page size

Next steps

• ZFS Pool Design: RAIDZ vs Mirrors — datasets and zvols both live on top of your vdev topology.
• iSCSI vs NFS vs SMB on TrueNAS — the protocol side of the dataset-vs-zvol choice.
• Setting Up SMB Shares on TrueNAS SCALE for the most common dataset use.
• ZFS Performance Tuning: ARC and recordsize — how record size and ARC caching shape real-world speed.

FAQ

What is the difference between a zvol vs dataset on TrueNAS? A dataset is a ZFS filesystem that stores files and folders and is shared over SMB or NFS. A zvol is a virtual block device that presents as a raw, unformatted disk, usually exported over iSCSI or attached to a VM. ZFS manages the files inside a dataset; with a zvol, the connected client formats and owns the filesystem itself.

When should I use a dataset vs zvol? Use a dataset for almost everything: SMB and NFS file shares, TrueNAS SCALE app data, and general storage where multiple devices read and write files. Choose a zvol only when a single consumer needs raw block storage, such as an iSCSI target or a VM disk. When in doubt, pick a dataset — it fits the vast majority of home NAS setups.

What is the default record size in TrueNAS? On current TrueNAS, a dataset’s recordsize defaults to 128K and acts as a dynamic ceiling, so ZFS still writes smaller records for smaller files. A zvol’s equivalent, volblocksize, defaults to 16K and is fixed at creation. The 128K record size suits most file workloads; raise it toward 1M for large sequential media such as video.

Can you change recordsize or volblocksize after creation? A dataset’s recordsize can be changed at any time, but it only affects data written afterward — existing records keep their old size until they are rewritten. A zvol’s volblocksize is permanent: it is chosen at creation and cannot be altered without destroying and recreating the zvol, so decide it before writing data.

Is a zvol faster than a dataset? Not inherently. A zvol can perform better for block workloads like databases or VM disks when its volblocksize matches the application’s I/O size, which avoids read and write amplification. For file sharing, a dataset is simpler and appropriately fast. Performance comes from matching the object and its tuning to the workload, not from the object type alone.

See also

• Docker homelab tutorials ↗