The ZFS Expansion Trap
We all love ZFS. It protects us from bit-rot, gives us lightning-fast ARC caching, and makes snapshots a breeze. But every TrueNAS admin eventually hits the wall known as the ZFS Expansion Trap.
Unlike traditional RAID setups where you can just toss a single new hard drive into your chassis to grow your array, ZFS is stubbornly rigid. If your primary pool is a 6-drive RAIDZ2 vdev, and you run out of space, you generally have two expensive choices:
- Buy an entirely new vdev (e.g., 6 brand new hard drives) to add to the pool.
- Replace all 6 of your existing drives one by one with larger drives, resilvering for days after every swap.
This means adding capacity costs hundreds, if not thousands, of dollars at a time. And what is filling up all that expensive, highly-redundant spinning rust? Usually, it's massive, cold files—old Plex movies, completed video projects, and archival backups that haven't been opened in months.
The Vdev Trap
The Infinite Pool
The Magic of ZFS Hole Punching
To fix the expansion trap, we need a way to move cold files off the ZFS pool without breaking the directory structure. Your Plex server, Nextcloud instance, and family SMB shares still need to see those files exactly where they were.
This is where HuskHoard utilizes one of ZFS's most powerful, yet underutilized features: Native Sparse Files (Hole Punching).
When HuskHoard's Janitor thread notices a 50GB video file hasn't been touched in 30 days, it reads the file and securely writes it to your offline tape pool or an encrypted S3 bucket. Then, HuskHoard issues a Linux fallocate (hole punch) command directly to the ZFS dataset.
ZFS responds to this command by literally deleting the underlying data blocks, instantly returning 50GB of free space to your pool. However, the file inode remains untouched. If you run ls -lh over SSH, or browse the folder in Windows Explorer, the file still says 50GB. It looks normal. But on the backend, ZFS is reporting that the file is taking up exactly 0 bytes of physical disk space.
Native Integration via Jailmaker
You might be wondering, "How do I install custom Rust software on a TrueNAS appliance without breaking the OS?"
The answer is Jailmaker (using systemd-nspawn). TrueNAS SCALE is based on Debian Linux, and Jailmaker allows you to spin up a persistent, lightweight Debian jail that acts just like a TrueNAS app, but gives you root-level control over the environment.
By using the --property="DeviceAllow=/dev/nst0 rwm" flag in your Jailmaker config, you can securely pass physical SCSI LTO Tape drives or cheap external USB drives straight into the HuskHoard jail. The jail also binds your main ZFS dataset (e.g., /mnt/tank/media), allowing HuskHoard to monitor filesystem events natively without relying on clunky network protocols.
Because it runs in a jail, HuskHoard survives TrueNAS OS updates. It doesn't pollute your host OS with dependencies, but it still gets direct, native-speed access to your ZFS datasets and your hardware.
Seamless SMB & Plex Streaming
So, you've punched holes in 20TB of old media. Your ZFS pool is empty and fast again. What happens when your wife opens Plex and tries to play a movie that was stubbed?
Because HuskHoard uses Linux fanotify directly against the ZFS mount inside the jail, it intercepts the read request the millisecond Plex tries to access the file. HuskHoard pauses the read, looks up the file in its SQLite catalog, and fires up its StreamGate engine.
StreamGate fetches the exact byte-range from your LTO Tape or Rclone cloud target and streams it directly back into the ZFS dataset. The file is reconstituted on the fly. Plex simply experiences a few seconds of buffering, completely unaware that the movie it is playing just materialized from a tape drive or cloud bucket.
The Economics of Offloading
The financial math of running HuskHoard on TrueNAS is impossible to ignore.
Let's say your 8-drive (8x 12TB) RAIDZ2 pool is 95% full. Upgrading that entire array to 18TB drives would cost roughly $1,600 and require weeks of stressful resilvering. Adding a completely new 6-drive vdev would cost around $1,200 and require buying a new HBA card and a larger chassis.
| Expansion Strategy | Upfront Cost | Power Impact | Administrative Effort |
|---|---|---|---|
| Replace drives (8x 18TB) | ~$1,600 | Same (8 drives spinning) | High (Weeks of resilvering stress) |
| Add new vdev (6x 12TB) | ~$1,200 + Hardware | Higher (14 drives spinning) | Medium (Chassis/HBA upgrades) |
| HuskHoard (1x LTO Tape / Cloud) | ~$30 (LTO-8) / Payload Cost | Lower (Core array sleeps more) | Zero (Automated Janitor tiering) |
Alternatively, you install HuskHoard, configure it to offload media older than 6 months, and point it at a cheap external USB drive, a used LTO tape drive, or a Backblaze B2 bucket. Overnight, HuskHoard punches holes in 40TB of old data. Your primary ZFS pool drops from 95% full to 40% full.
By leveraging ZFS's native support for sparse files, HuskHoard safely reclaims disk blocks while leaving your directory trees and file metadata completely intact for SMB/NFS clients.
Run HuskHoard seamlessly on TrueNAS SCALE without virtual machine overhead. Get direct access to ZFS and SCSI hardware while remaining securely isolated from the host OS.
Escape the RAIDZ vdev trap. Expand your cold storage capacity one disk or one tape cartridge at a time, exactly when you need it, for a fraction of the cost.
The Verdict
TrueNAS provides the ultimate foundation for data integrity, but you shouldn't be forced to store cold, dead data on your most expensive, power-hungry tier. By pairing TrueNAS SCALE with HuskHoard via Jailmaker, you break the ZFS expansion trap forever.
Keep your hot data safe on ZFS. Let HuskHoard seamlessly push everything else to tape or cloud. Your wallet, and your chassis thermals, will thank you.