The File System Holy Wars (and why they miss the point)
If you ask a sysadmin what the "best" file system is, you are going to start an argument. In the HuskHoard test lab, we default to XFS. It is an older filesystem, but it is a rock-solid, high-performance workhorse that handles parallel I/O brilliantly.
However, we know that suggesting XFS over ZFS or ext4 in certain circles is considered heresy. ZFS fans rightfully point out its unmatched data integrity, snapshotting, and volume management. Ext4 purists love its simplicity and ubiquitous Linux support.
But here is the dirty secret of storage engineering: At scale, all file systems suffocate.
It doesn't matter if you are running the most perfectly tuned ZFS zpool or a blazing-fast XFS array on NVMe drives. When you start throwing massive archival workloads at them, the underlying B-trees, inode tables, and fragmentation physics begin to buckle. The goal of HuskHoard isn't to force you to abandon your favorite file system—it’s to act as a pressure valve so your file system can do what it does best.
The Four Horsemen of File System Death
When building an archive, your "Hot Tier" (the SSD where users interact with files) faces four distinct, physical problems that degrade performance:
While ext4 wastes block space on tiny files and can permanently run out of fixed inodes, dynamic file systems like XFS and ZFS face a different demon: Metadata Thrashing. A million small files mean a million random I/O operations for your backup software and massive fragmentation across your metadata tree.
When dealing with 500GB video files or database dumps, modifying or reading the middle of the file causes massive fragmentation. Moving these files across tiers locks up I/O threads.
Try running ls -l in a directory with 500,000 files. Your terminal hangs while the file system scrambles to read the metadata of half a million scattered inodes.
This is the big one. For Copy-on-Write (CoW) systems like ZFS, passing 80% capacity is fatal; free space fragments, and finding "holes" for new writes causes performance to fall off a cliff. Even on overwrite-in-place systems like XFS or ext4, keeping your Hot Tier SSDs below 80% is critical for TRIM and wear-leveling algorithms to function properly.
XFS vs. ZFS: Choose Your Fighter
Let's look at how our two favorite enterprise filesystems handle these problems out of the box.
Advanced but Heavy
Fast but Basic
As you can see, ZFS fixes some of XFS's problems (compression, bit-rot), but introduces its own (RAM usage, 80% cliff). HuskHoard is designed to solve all of these problems for both of them.
The HuskHoard Way: Punching Holes and Offloading Pain
HuskHoard runs natively on your Hot Tier (your XFS or ZFS SSD). But instead of letting the file system choke on the data, it uses a background daemon to intercept and surgically remove the burden.
Here is how HuskHoard breaks your file system out of its limitations:
libc::fallocate()Let's look at how this specifically addresses the Four Horsemen:
1. Solving the Capacity Problem (The 80% Cliff)
In the HuskHoard config, we use a setting called hot_tier_max_usage_percent = 80. Before your ZFS or XFS volume ever hits that dangerous fragmentation threshold, the Janitor thread wakes up. It safely copies your oldest files to the backend raw archive, and then executes a Linux system call: FALLOC_FL_PUNCH_HOLE.
The file is stubbed. Your file system still sees the file. It still reports the correct file size, owner, and modification date to SMB/NFS users. But the actual payload space consumed on the SSD becomes zero. Your file system never fills up, meaning it never slows down. (Note for ZFS users: OpenZFS 2.0+ supports hole-punching natively, just be sure to rotate your snapshots so the underlying blocks are actually freed!)
2. Solving the Small File Problem (Metadata Exhaustion)
When a filesystem like XFS or ZFS handles a million 1KB files, it’s not just the data that kills performance—it’s the bookkeeping. Each file needs an inode, a journal entry, and a spot in the directory tree. This creates "Metadata Thrashing."
HuskHoard changes the game. It compresses each file individually—ensuring you can still retrieve a single file in milliseconds—but it packs them sequentially. Using a 256KB AlignedBuffer, HuskHoard lines up your files like cars on a train. Instead of a million tiny random writes that make your disk heads scream, the archive drive receives one long, smooth, continuous stream of data.
The result? Your Hot Tier SSD is cured of metadata bloat, your archive drive avoids the random I/O "death by a thousand cuts," and your small files are stored sequentially with BLAKE3 integrity in a fraction of the time.
3. Solving the Large File Problem
What happens when a user clicks a stubbed 500GB video file to watch a specific scene? HuskHoard's StreamGate logic kicks in. The daemon intercepts the read request using fanotify. Because HuskHoard packed the file in 16MB Zstd frames, it can instantly calculate exactly which frame holds that timestamp, seek directly to it via O(1) lookup, and stream just that byte-range back to the user without restoring the whole 500GB file.
Because HuskHoard uses libc::fanotify_init(libc::FAN_CLASS_PRE_CONTENT, libc::O_RDWR), the intercept happens at the kernel VFS layer. The application (VLC, Premiere, Windows Explorer) has no idea the file was stored on tape. It just reads it normally.
The Archival Benchmark: Making Every File System Shine
By offloading the heavy lifting to a raw-block backend and a lightning-fast SQLite catalog (husk_catalog.db), HuskHoard acts as an exoskeleton for your file system.
| Limitation | Standard XFS / ZFS | With HuskHoard Daemon |
|---|---|---|
| Approaching 100% Full | Severe fragmentation, massive slowdown | Auto-stubs at 80%; performance stays pristine |
| Small File Overhead | High random IOPS & metadata bloat | Packed sequentially into 16MB Zstd frames |
| Data Integrity (XFS/ext4) | Silent bit-rot possible | HuskHoard applies BLAKE3 hashing to all files |
| Archive Storage Cost | Requires building new ZFS vdevs/RAID arrays | Dumps sequentially to raw, cheap SMR/LTO Tape |
This is why we want HuskHoard to be inclusive. We love XFS for its sheer speed on our NVMe drives. If you love ZFS, HuskHoard will seamlessly integrate with your ARC cache and snapshots while keeping your zpool cleanly under 80% capacity.
Keep millions of files instantly visible to your network users while consuming near zero bytes of physical SSD space.
Instead of thrashing your file system's metadata tree, HuskHoard's SQLite catalog provides instant offset lookups for any file.
Whether you format your Hot Tier with XFS, ZFS, ext4, or BTRFS, HuskHoard operates at the kernel level to make them all perform flawlessly.
The Verdict
The file system holy wars are fun, but they distract from the real issue: treating an active NVMe tier the same way you treat a petabyte-scale cold archive.
You don't need to choose between the speed of XFS and the safety of ZFS. Pick the one you are most comfortable administering, install HuskHoard on top of it, and let the software handle the physics of scale.
* 0 bytes of payload! A true "0 bytes" would mean no file exists. The file system still retains the inode (typically 256 to 512 bytes on XFS/ext4) and metadata to represent the sparse stub. We will talk more about metadata footprint in another post.