In this article
  1. The Hardware RAID Trap
  2. Reed-Solomon and the Magic of 4+2
  3. Bypassing the Kernel: O_DIRECT & Crossbeam
  4. Green IT: Spindle Power Management
  5. The "Virtual Tape" Abstraction
  6. Why We Built It in the Sidecar

The Hardware RAID Trap

If you've managed a storage server in the last two decades, you are intimately familiar with hardware RAID. You buy a PCIe card, plug 8 to 24 hard drives into it, and configure it as RAID 6. The operating system just sees a single, massive logical drive (e.g., /dev/sdb).

The problem arises when things break. Hardware RAID arrays are tied to the proprietary silicon that created them. If your LSI or Broadcom RAID card dies, you can't just plug those drives into your motherboard—you have to source the exact same RAID card with the exact same firmware revision, or you lose the entire array. Furthermore, rebuild times on modern 20TB+ hard drives can take days, during which the array is vulnerable and agonizingly slow.

Hardware RAID (Metal)

Rigid & Proprietary

Data protection is handled by a locked black-box silicon chip. If the chip dies, the data is unreadable by standard operating systems. Rebuilds require scanning every single sector of the physical disks sequentially.

Erasure Coding (Math)

Fluid & Portable

Data protection is handled by open-source math (Reed-Solomon) executed by the CPU. The hard drives can be moved to any machine, anywhere. Rebuilds only recalculate the specific files that were lost, not empty drive space.

For an active archive like HuskHoard, where data might sit untouched for months but needs to be perfectly intact for decades, being locked to a specific PCIe controller is a massive operational liability. We needed a better way.

Reed-Solomon and the Magic of 4+2

Instead of hardware RAID, the Husk Enterprise Sidecar utilizes Software-Defined Erasure Coding (EC), specifically using Reed-Solomon math operating in a Galois Field (2^8). This is the exact same mathematics used to ensure data arrives safely from deep space probes.

By default, Husk configures its EC Pools (or "Cells") in a 4+2 layout. This means we have DATA_SHARDS = 4 and PARITY_SHARDS = 2. When the Husk Core sends a stream of data to the Sidecar, it doesn't write it to disk immediately. It holds the data in RAM until it has a full 4-Megabyte chunk, known as a Stripe.

It chops that 4MB into four 1MB data shards. Then, the Reed-Solomon engine calculates two additional 1MB parity shards. We now have 6 total shards.

// Inside handle_ec_write: Slicing the buffer and encoding const STRIPE_SIZE: usize = 4 * 1024 * 1024; // 4MB Buffer const SHARD_SIZE: usize = STRIPE_SIZE / 4; // 1MB per data drive // Break the 4MB buffer into 4 exact chunks let mut shards: Vec<Vec<u8>> = buffer.chunks_exact(SHARD_SIZE) .map(|chunk| chunk.to_vec()).collect(); // Allocate space for the 2 Parity shards for _ in 0..2 { shards.push(vec![0u8; SHARD_SIZE]); } // Run the Reed-Solomon Math ec_engine.encode(&mut shards).expect("EC Math Failed");

The mathematical magic of Reed-Solomon is that any 4 of those 6 shards can perfectly reconstruct the original 4MB stripe. You can lose drive 1 and drive 2. You can lose drive 3 and drive 6. It doesn't matter. As long as 4 shards exist, the CPU can solve the polynomial equations and rebuild the missing bytes on the fly in milliseconds.

Bypassing the Kernel: O_DIRECT & Crossbeam

Math is great, but getting it onto physical rust-and-platter hard drives quickly requires bypassing the operating system's standard behaviors. Normally, when you write a file in Linux, the OS buffers it in the "Page Cache" in RAM, writing it to disk whenever it feels like it. For a 10KB text file, this is great. For a 2TB ProRes video archive, this destroys system memory and causes massive I/O bottlenecks.

The Husk Sidecar circumvents this entirely. When it writes the 6 shards to the 6 drives in the Cell, it uses a system flag called O_DIRECT. This tells the Linux kernel: "Do not cache this. Send these exact bytes directly to the physical disk controller right now."

1
Buffer Stream
Sidecar ingests bytes via UDS until the 4MB stripe buffer is full.
ram
2
EC Encoding
Reed-Solomon CPU math generates the 6 total shards (4 data, 2 parity).
cpu
3
Crossbeam Threads
Spawns 6 OS threads simultaneously using crossbeam::scope to prevent bottlenecking.
sidecar
4
O_DIRECT Write
The 6 shards hit the physical drives at the exact same time, bypassing OS caching entirely.
hardware

By using Rust's fearless concurrency via crossbeam::scope, all 6 drives write their 1MB chunks in parallel. Since the write bandwidth of a modern HDD is about 250MB/s, a 6-drive Husk Cell can comfortably ingest archive data at over 1,000 MB/s—saturating a 10GbE network link without ever touching the OS page cache.

Green IT: Spindle Power Management

Because the Sidecar operates directly on the block devices (e.g., /dev/sda) rather than relying on a dumb RAID controller, it knows exactly when the drives are being used and when they aren't. In a massive petabyte-scale archive, 90% of your data will not be read on any given day.

If you leave thousands of hard drives spinning 24/7, you burn an exorbitant amount of electricity, generate massive heat (requiring more AC), and drastically reduce the mechanical lifespan of the drive bearings. Husk solves this with the Spindle Manager.

01 — Idle Detection
The 10-Minute Rule
The Sidecar maintains a last_accessed timestamp in RAM for every EC Cell. An asynchronous background loop checks this every 30 seconds. If a Cell hasn't been touched in 600 seconds (10 minutes), it takes action.
02 — Power Down
Issuing hdparm -y
The Sidecar issues a hardware STANDBY command directly to the 6 drives in the idle Cell. The physical disks stop spinning, dropping power consumption per drive from ~8 watts down to ~1 watt.
03 — Instant Wake
WAKE_VOLUME Event
If a user requests a file on a sleeping Cell, the Core fires a WAKE_VOLUME event. The Sidecar catches it, spins the 6 drives back up, and serves the data. The user just experiences a brief ~8-second delay.
04 — ROI
Massive TCO Drops
For a 2,000 drive archive, aggressive spindle management can reduce power consumption by over 14,000 watts an hour, slashing datacenter power and cooling bills while extending drive longevity by years.

The "Virtual Tape" Abstraction

To keep the system architecture clean, the core Husk daemon doesn't actually know how Erasure Coding works. The core engine is built to write streams of data to LTO Tape drives. It expects to stream data linearly to a destination and catalog it.

We used this existing architecture to our advantage. To the Husk Core, a 6-drive EC array isn't a hard drive array at all—it's just a "Virtual Tape."

01
Core Issues a Tape Write
The main Husk daemon says "Write this file to Tape UUID VIRTUAL_EC_POOL_1 at offset 0."
02
Sidecar Intercepts
The sidecar catches the EC_WRITE event. It looks up VIRTUAL_EC_POOL_1 in its state lock and realizes it maps to physical drives sda through sdf.
03
Translation & Execution
The sidecar translates the linear tape offset into physical physical block offsets for the 6 drives (offset / DATA_SHARDS), runs the math, and commits the write.
04
Database Sync
The Core catalogs the file exactly as if it were on a physical LTO tape cartridge, making tracking and retrieval entirely uniform across both disk and tape tiers.

Why We Built It in the Sidecar

By moving the heavy lifting of Erasure Coding out of the core daemon and into the Rust sidecar, we created a strict separation of concerns. If the Sidecar panics because a drive completely locked up the SCSI bus, the main Husk daemon keeps running, continuing to serve files from SSD cache and active tape drives.

Furthermore, because the Sidecar is built asynchronously on top of the Tokio runtime, holding a lock to calculate Reed-Solomon math on one EC Cell doesn't block another thread from spinning up an idle Cell or serving a Prometheus telemetry request on the HTTP port.

No More Vendor Lock-in

Because the math is entirely open-source, if you ever decide to stop using HuskHoard, you don't lose your data. A simple open-source Python script could read the 6 raw shards from the block devices and decode the Reed-Solomon equations to reconstruct your archive files. Try doing that with a dead hardware RAID controller.

Storage shouldn't rely on brittle metal and proprietary silicon. By replacing hardware RAID with intelligent, software-defined math, the Husk Enterprise Sidecar makes massive disk archives faster, greener, and ultimately, immortal.