TrueNAS Datasets vs Zvols: When to Use Which

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. They sound 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.

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.

recordsize vs 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.

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.

See also

• Docker homelab tutorials ↗