In this article
  1. The Fragility of Cron and Rsync
  2. Cryptographic Integrity on the Fly
  3. The Multi-Tape Multiplexer
  4. Hole Punching: The OS Magic Trick
  5. Emergency Spillover

The Fragility of Cron and Rsync

In most tiered storage deployments, the "hot" NVMe pool and the "cold" archive pool are treated as two distinct silos. To bridge them, administrators typically rely on a fragile web of bash scripts running rsync via cron in the middle of the night.

This is a terrifying way to manage petabytes of data. What happens if a user is writing to a 200 GB video file right as the cron job fires? You get a corrupted archive. What happens if the network drops halfway through? You get orphaned chunks. What happens if the file permissions change during the transfer?

Traditional Workflow

Bash & Rsync

✗Blindly runs on intervals, regardless of file lock status
✗Requires a second pass to verify data integrity
✗Sequential transfers to backup destinations
✗Moving files breaks software linking to the original path
HuskHoard

The Janitor Daemon

✓Listens to OS-level FAN_CLOSE_WRITE events in O(1) time
✓Cryptographic BLAKE3 hashing streamed directly in the pipeline
✓Multiplexed simultaneous writes to primary and replica targets
✓Hole-punched stubs leave the filesystem path completely intact

HuskHoard handles data migration at the operating system kernel level. Because our daemon intercepts fanotify events, we never need to crawl the disk looking for changed files. When a user finishes modifying a file, the OS instantly queues it in HuskHoard's active_tracking table. The Janitor simply wakes up, looks at the queue, and elegantly moves the cold data.

Cryptographic Integrity on the Fly

Silent data corruption (bit-rot) is the greatest enemy of cold storage. A flipped bit in a massive .mkv or .tar file on an LTO tape might not be discovered for years. If your background mover isn't verifying bits as they cross the wire, you are gambling.

We designed HuskHoard's archiver with a strict zero-trust policy. As data streams from the NVMe disk to the tape device (or cloud target), it passes through a Rust wrapper we call the HashWriter.

// From src/engine.rs — Calculating hashes inside the write pipeline struct HashWriter<W: std::io::Write> { inner: W, hasher: blake3::Hasher, } impl<W: std::io::Write> std::io::Write for HashWriter<W> { fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> { let n = self.inner.write(buf)?; self.hasher.update(&buf[..n]); Ok(n) } }

Because BLAKE3 is obscenely fast (capable of hashing multiple gigabytes per second), it never bottlenecks the hardware. Once the transfer is complete, the final BLAKE3 hash is injected directly into a 4KB `ObjectHeader` written to the start of the tape block. Whenever that file is read back, HuskHoard verifies the hash mathematically before delivering a single byte to the user.

The Multi-Tape Multiplexer

Archiving data safely means maintaining multiple copies (the 3-2-1 rule). But reading a massive video file from an SSD three separate times to write it to three separate archive volumes causes unnecessary wear and tear on your drives.

HuskHoard solves this with the MultiTapeWriter. When the Janitor picks up a file to archive, it evaluates the database and opens file descriptors for your Primary, Failover, and Replication volumes simultaneously. It reads a chunk of data from the source disk exactly once, buffers it, compresses it with `zstd`, and blasts it to all target locations in parallel.

BLAKE3
In-Flight Hashing

Zero-cost cryptographic verification happens inside the stream pipeline to prevent bit-rot.

256 KB
Hardware Alignment

The multiplexer pads data into 256KB RAM buffers to match the optimal physical block sizes of LTO tape drives.

O(1)
Event-Driven Tracking

No agonizing `find` or `rsync` crawls. Changes are recorded to the SQLite queue in microseconds.

Crucially, the MultiTapeWriter uses `alloc_zeroed` to generate perfectly aligned 256KB memory blocks. Standard operating system I/O can cause SCSI tape drives to "shoe-shine" (start and stop rapidly) if the blocks are mismatched. HuskHoard forces the data into perfect physical hardware boundaries, maximizing tape throughput and drive lifespan.

Hole Punching: The OS Magic Trick

This is where the magic happens. What actually happens to the original file after it's safely copied to the archive?

If you just rm the file and replace it with a symlink, desktop applications will break. Video editing software like Premiere or Resolve will immediately flag the media as missing because the inode changed. Instead, HuskHoard performs a surgical operation: Hole Punching.

// From src/daemon.rs — The magic trick let mode = libc::FALLOC_FL_PUNCH_HOLE | libc::FALLOC_FL_KEEP_SIZE; unsafe { libc::fallocate(fd, mode, 0, file_size as libc::off_t) };

By asking the Linux kernel to punch a hole through the file (FALLOC_FL_PUNCH_HOLE), the file system physically deletes the 1s and 0s from the SSD, freeing the space. However, it uses FALLOC_FL_KEEP_SIZE to lie to the operating system. If a user runs ls -l, the file still says it is 50 GB. The icon remains the same. The POSIX permissions (uid/gid) remain identical. But it takes up 0 bytes on the drive.

We then quietly attach an extended attribute (trusted.husk.status = "stubbed") and use utimensat to roll the modified time (mtime) back to exactly what it was before we touched it. To the end user—and to the file system—nothing ever happened.

Emergency Spillover

A good storage system doesn't just run on a schedule; it reacts to physics.

Normally, the Janitor thread waits for files to hit a `max_age_days` threshold before archiving them. But production environments are chaotic. A 10-camera multi-cam shoot could easily ingest terabytes of data in a few hours, risking a completely full NVMe drive.

High-Water Marks

HuskHoard implements an emergency spillover protocol. If the Janitor detects that the Hot Tier has exceeded a configured threshold (e.g., 80% full), it bypasses the age requirement. It sorts the active tracking queue by the oldest unmodified files first, and aggressively archives and hole-punches them until the drive returns to a safe capacity.

This guarantees your ingest volumes never run out of space during a critical transfer, seamlessly turning your limited hot SSD into a bottomless cache.

Moving Data is a Science

Storage engineering isn't just about saving data to disk; it's about the lifecycle of how that data flows through tiers of hardware. By ditching brittle bash scripts and building a transactional, cryptographically verified, perfectly-aligned multiplexer in Rust, HuskHoard turns file archiving from a terrifying nightly cron job into an invisible, bulletproof feature of the operating system itself.