The "Tape and SMR Only" misunderstanding
Let’s set the record straight: Yes, HuskHoard was fundamentally designed around the physics of sequential LTO tape drives. Yes, that exact same design makes it the undisputed king of managing cheap SMR (Shingled) hard drives. But if you have a stack of high-quality CMR (Conventional Magnetic Recording) drives—like WD Reds, Seagate IronWolfs, or enterprise Exos drives—you shouldn't be forcing them into a standard RAID array either.
The problem with modern storage isn't just about how data is written to the platters. It's about how traditional filesystems treat the mechanical reality of a spinning disk.
To understand why HuskHoard is the ultimate destination for your CMR drives, we have to look at the massive architectural flaw in how standard NAS arrays handle power management.
RAID: The 24/7 Spin Cycle
Let's say you build an 8-drive RAID-Z2 pool using standard 12TB CMR NAS drives. You dump 50TB of movies, family photos, and backups onto it. You might only watch one movie a week, or look at those photos once a month. Logically, those drives should be asleep 99% of the time.
But they aren't.
Because RAID stripes your data across all the disks, reading a single 2GB video file requires all eight drives to spin up simultaneously. Furthermore, traditional filesystems like ZFS or ext4 scatter metadata (directory structures, inodes, free space bitmaps) across the platters. Every time your operating system does a routine background index, checks free space, or a network protocol like Samba pings a directory, the entire array wakes up.
The "Always On" Array
Independent Volumes
This 24/7 spin cycle is a disaster for power consumption and mechanical wear. Eight drives idling at 6-8 watts each is pulling roughly 60 watts continuously. That’s a 500 kWh annual penalty just to keep metal spinning for data you aren't even actively using.
The Power of the Deep Sleep
This is where HuskHoard dramatically changes the game for CMR drives. In HuskHoard, we treat hard drives as pure "payload tanks." The filesystem metadata doesn't live on the drives at all.
Instead, HuskHoard maintains a centralized SQLite database (husk_catalog.db) strictly on your lightning-fast Hot Tier (NVMe SSD). When you run an ls command, search for a file, or a media scraper like Plex scans your library, the OS is entirely interacting with 0-byte sparse file "stubs" on the SSD.
Because the CMR drives are bypassed for all standard POSIX filesystem chatter, they can confidently spin down and enter their lowest power states. They literally pull just a few watts for weeks at a time. When a file is finally requested, HuskHoard looks up its exact physical offset in the SQLite catalog and wakes up only the specific independent volume containing that file's replica.
Keeping a drive spun down isn't just about saving your electricity bill. Heat and continuous bearing rotation are the leading causes of mechanical failure in CMR drives. By letting your archive drives sleep, you exponentially increase their physical lifespan.
Performance: Why CMR Loves Append-Only
Even though CMR drives don't suffer from the catastrophic write-amplification of SMR, they still possess physical read/write heads that have to physically seek across platters. Random writes cause fragmentation, forcing the head to violently jerk back and forth, reducing your write speeds to a fraction of the drive's potential.
HuskHoard completely eliminates fragmentation. Our engine buffers incoming files in RAM, compresses them with Zstd into massive 16MB frames, and then writes them to the CMR drive using Linux O_DIRECT in strictly 4KB-aligned blocks.
The write head locks into place and simply streams data sequentially until the drive is full. This means your CMR drive will achieve its absolute maximum theoretical throughput (often 200-250+ MB/s) from the very first gigabyte to the very last, with zero mechanical thrashing.
Economics: The End of the RAID Rebuild
Beyond power savings and pure sequential throughput, using CMR drives in HuskHoard frees you from the most terrifying experience in homelab storage: The RAID Rebuild.
When a 14TB drive fails in a RAID-Z2 array, the remaining drives must be kept awake and stressed to 100% capacity for days on end to recalculate parity data. A second drive failure during this window can wipe out the entire pool.
| Architecture | Power Draw (8x 12TB) | Failure Domain | Rebuild Stress |
|---|---|---|---|
| Standard RAID-Z2 | ~60W Constant | Pool Level (Lose pool, lose everything) | Extreme (Days of 100% I/O load) |
| HuskHoard Replicas | ~0W (Spun down) | Drive Level (Only isolated files lost) | None (Just copy missing files from replica) |
In HuskHoard, drives are independent. If CMR Drive #2 dies, you don't lose the array. You just pull it out. HuskHoard seamlessly fails over to the replica copy on Drive #4. To restore redundancy, the background worker simply copies the missing files sequentially to a new drive. No parity math, no pool-wide stress tests, no white-knuckle rebuilding.
Because HuskHoard’s catalog lives on your SSD, the OS never needs to wake up the CMR drive for metadata checks. The drive can spin down completely, pulling 0 Watts until actively requested.
Escape the RAID trap. HuskHoard stores whole files on independent filesystems. If a drive fails, you only lose the data on that specific piece of hardware—which is instantly served by your failover replica.
By buffering data in RAM and using O_DIRECT aligned writes, HuskHoard ensures zero fragmentation, extending the life of your bearings and maintaining peak platter throughput.
The Verdict
It's time to stop thinking of HuskHoard as just a "tape alternative." It is a fundamental rethinking of how cold and warm data should interact with mechanical hardware.
If you have a stack of high-quality CMR NAS drives, sticking them in a RAID array forces them to run a marathon every single day. Format them as HuskHoard volumes instead. Let them sleep. Let them run cool. And let your archive operate with the efficiency it deserves.