What’s up guys, welcome or welcome back to the blog. Today we’re continuing our TrueNAS SCALE deep dive, picking things up where we left off with storage. In Part 1, we broke down disks, VDEVs, and pools, basically the foundation of your ZFS storage. If you missed that one, definitely check it out first because everything we’re about to talk through builds right on top of it.
In this post, we’re finally moving up the stack and getting into datasets, ZVOLs, and the different share types TrueNAS offers. Instead of a click-here, click-there guide, this is about understanding why these pieces exist, what role they play, and how they all fit into a clean, well-designed storage workflow. We're breaking things down layer by layer.
The Storage Flow (Big Picture)
Before diving deeper, it helps to remember the overall structure of ZFS: Disks → VDEVs → Pool → Datasets / ZVOLs → Shares. Disks and VDEVs form the foundation. The pool sits on top of that. And datasets, ZVOLs, and shares are the layers you actually interact with day-to-day. Everything in this post happens above the pool level.
Datasets — Your Rooms Inside the House
A dataset is one of the most powerful concepts in ZFS. The best way to picture it is like a room inside your storage house. The pool is the house; datasets are the rooms with their own locks, rules, and purposes.
Each dataset:
- Lives inside your pool
- Can have its own settings, such as compression or atime
- Manages its own permissions and ACLs
- Can be shared independently
- Helps you keep your data organized and separated
So you could have:
- A dataset for media
- Another for backups
- Another for VMs
- Another for documents
All sharing the same physical storage, but each behaving differently. And yes datasets can contain datasets, and those can contain more datasets. It’s extremely flexible.
ZVOLs — Virtual Disks Backed by ZFS
Inside the dataset section, you can also create ZVOLs. A ZVOL is a virtual block device, similar to a virtual hard drive. It still lives inside your pool and gets all the ZFS benefits, but instead of storing files, it behaves like a raw disk. You’d use a ZVOL when something needs block storage, not file storage. Think virtual machines, databases, or iSCSI targets.
A simple way to think about it:
- Dataset = shared folder (file storage)
- ZVOL = virtual disk (block storage)
Both are part of ZFS, but they serve very different roles.
Snapshots: Save Points, Not Backups
Snapshots are one of those “once you use it, you can’t live without it” features. A snapshot captures your dataset or ZVOL at a precise moment in time.
It’s perfect for:
- Rolling back after a big change
- Testing something without fear
- Quickly cloning a dataset
But here’s the thing many people misunderstand:
- A snapshot is not a backup.
Snapshots live inside the same pool. If your pool fails, the snapshots go with it. They’re a safety net super useful, super powerful but not a replacement for replicating your data to another system or off-site location.
The System Dataset: Where TrueNAS Stores Its Own Stuff
TrueNAS needs a place to keep its own internal data, like logs, metrics, and system metadata. That’s stored in something called the system dataset. Here’s the part most people don’t realize:
- When you first install TrueNAS, the system dataset may start on the boot device.
- As soon as you create your first pool, TrueNAS usually moves it to that pool.
- If you later delete that pool, TrueNAS automatically moves the system dataset back to the boot device until a new pool exists.
The idea is simple: avoid wearing out the boot drive and keep system operations on the more durable pool storage. Wherever the system dataset lives, that’s where you’ll see certain “global” settings and advanced options appear — because those settings follow the system dataset.
Shares — The Doorways Into Your Storage
Datasets and ZVOLs are internal pieces. To actually use your storage over the network, you expose them through shares. Shares are the doorways into your pool. They decide how other devices access your data and what protocol they use.
TrueNAS SCALE supports four major share types:
- SMB (Windows / multi-OS file sharing)
- NFS (UNIX/Linux file sharing)
- iSCSI (block storage for hypervisors and servers)
- NVMe-oF (ultra-fast block storage over network fabrics)
Each one is built for different workloads and different clients. Let’s break each down.
SMB (Windows File Sharing): SMB is the protocol Windows uses for network file sharing, and TrueNAS uses the open-source Samba implementation to support it.
It’s designed for:
- Multi-user environments
- Authentication with usernames and passwords
- Detailed permission control
- Integration with Active Directory
Even though SMB is “Windows-native,” Linux and macOS can mount it too. It’s universal. Use it when you want easy file sharing with proper user-based access control.
NFS (UNIX/Linux File Sharing): NFS is the native file-sharing protocol for Linux and UNIX systems. It's known for:
- Speed
- Low overhead
- Simple integration
The key difference from SMB is authentication. NFS doesn’t use usernames and passwords. Instead, it trusts the client’s UID/GID.
That makes it extremely fast but only safe inside trusted networks. You typically lock NFS down to IP ranges or specific hosts.
iSCSI (Block Storage Over the Network): iSCSI is completely different from SMB and NFS. Instead of sharing files, iSCSI presents a raw disk over the network.
The machine connecting to it thinks you physically plugged in a new drive. This is why it’s commonly used for:
- Hypervisors (Proxmox, ESXi, Hyper-V)
- Databases
- Any workload that needs direct block storage
TrueNAS breaks iSCSI into a few building blocks:
- Targets — endpoints clients connect to
- Extents — the actual block devices (ZVOLs or disk image files)
- Initiators — which hosts are allowed to connect
- Portals — the network interfaces iSCSI listens on
Once you understand those four pieces, the whole iSCSI system starts to make sense.
NVMe-oF — NVMe Performance Over the Network: NVMe-oF stands for NVMe over Fabrics, and it’s the newest and fastest protocol on this list. With NVMe-oF, another machine on your network can access your NVMe storage almost as if the drive were physically installed in that machine.
It behaves like:
- You pulled an NVMe stick out of your server
- And let another machine use it
- Without ever touching the hardware
In real life, it’s perfect for VMs, databases, and anything that wants high-performance block storage. Your backend storage doesn’t have to be NVMe, but you won’t get NVMe-level performance without NVMe drives backing it.
NVMe-oF usually requires:
- A static IP
- Stable networking
- A clean, low-latency path
Because this protocol is all about speed and reliability.
Putting It All Together
At this point, you should have a clear understanding of how everything fits together:
- Pools store your data.
- Datasets organize it.
- ZVOLs act as virtual disks.
- Snapshots give you save points.
- The system dataset handles TrueNAS internals.
- Shares expose everything to your network.
This is the structure you’ll lean on again when you start working with:
- Virtual machines
- Containers
- Applications
- External servers and hypervisors
Pretty much everything in TrueNAS sits on top of what we covered here.
Final Thoughts
The next video and blog in this series will dive into permissions, users, groups, ACLs, and how to set your storage up the right way. Permissions are their own world, and they can make or break your entire storage setup, so we’ll give it the deep dive it deserves. As always, If you found this helpful, share it with someone else on their TrueNAS journey, and feel free to jump into the comments or Discord if you want to chat about your setup. Stay geeking, stay curious, and I’ll see you in the next one. Peace
