The Spinning Tax
We have a bad habit in the IT industry of confusing "available" with "spinning." Because standard POSIX filesystems and hardware RAID controllers expect underlying block devices to respond in milliseconds, we leave massive arrays of platters spinning at 7,200 RPM, 24 hours a day, 365 days a year.
This generates heat, which requires HVAC cooling, which consumes even more power. It also constantly wears out the fluid dynamic bearings inside the drives. If 95% of the data in your archive hasn't been touched in the last six months, why are you paying to keep the physical platters rotating beneath the read/write heads?
The Always-On Tax
If you spin down a single drive in a RAID 6 array, the RAID controller often assumes the drive has failed and degrades the array. Thus, all drives must spin constantly, drawing ~7W each just to idle.
Wake-on-Demand
Husk manages disks purely in software as individual targets. A 6-disk Erasure Coding cell can be fully powered down. When a read request hits the OS, Husk pauses it, wakes the cell, and serves the data.
Tape: The Zero-Watt Baseline
When we built HuskHoard, we started with LTO Tape. Tape is the ultimate green storage medium. A cartridge sitting on a shelf consumes exactly 0.00 watts of electricity. It generates zero heat. It suffers zero mechanical wear.
However, tape has a physical penalty: latency. When a user requests a file on tape, a robot arm has to fetch the cartridge, insert it into a drive, thread it, and spool to the correct block. This can take anywhere from 45 to 90 seconds. For deep archives, this is perfectly acceptable (and handled gracefully by Husk's fanotify intercept). But what about the "Warm" tier? Data that isn't accessed daily, but needs to be retrieved in seconds, not minutes?
We needed a way to build a disk-based tier that behaves like tape when idle, but acts like disk when queried.
SMR Drives and Sequential Sharding
To build a massive, cheap warm tier, the industry relies on SMR (Shingled Magnetic Recording) hard drives. SMR drives achieve massive capacities by overlapping data tracks like shingles on a roof. They are cheap, but they have a fatal flaw: random writes are excruciatingly slow because modifying one track requires rewriting the adjacent, overlapping tracks.
Because of this, traditional ZFS or hardware RAID setups absolutely despise SMR drives.
But Husk doesn't write randomly. Husk's software-defined Erasure Coding engine buffers incoming data into 4MB stripes in RAM, calculates parity, and then writes perfectly sequential 1MB shards down to the raw block devices using O_DIRECT.
Because HuskHoard acts as a Write-Once-Read-Many (WORM) append-only archiver, it never executes random overwrites. This makes Husk the perfect controller for ultra-cheap, ultra-dense SMR drives. We get the density of shingled platters without suffering the write penalties.
The Spindle Manager (hdparm)
To solve the idle power problem, the Husk Sidecar includes a background worker called the Spindle Manager.
Because Husk is fully aware of every Erasure Coding "Cell" (a logical grouping of drives), it tracks exactly when a cell was last accessed. If a cell hasn't been read from or written to in 10 minutes, the Sidecar executes a standard Linux ATA command (hdparm -y) to put all the drives in that cell into Standby mode.
Standby mode stops the motor and parks the heads. This drops the power consumption of a standard enterprise HDD from ~7.5W down to roughly 1W. Across a 60-bay chassis, you've just dropped your power draw from 450W to 60W.
But 1W is still not 0W. The drive's logic board is still powered on, listening on the SATA/SAS bus. We wanted to go further.
Enter Pin 3: Hardware Power Severing
With the release of the SATA 3.3 specification, the consortium introduced a feature called PWDIS (Power Disable). It repurposed Pin 3 on the SATA power connector. If a host system pulls Pin 3 high (3.3V), the hard drive completely cuts power to its internal circuitry. It is the electronic equivalent of yanking the power cable out of the back of the drive.
Historically, this feature annoyed home-labbers who "shucked" external Western Digital drives, as older power supplies permanently supplied 3.3V to Pin 3, preventing the drives from ever turning on (hence the famous "kapton tape over Pin 3" trick).
But for HuskHoard, Pin 3 is a superpower.
In upcoming releases, the Husk Enterprise Sidecar is introducing direct integrations with intelligent SAS backplanes and GPIO headers. Instead of just sending a soft hdparm command, Husk will physically kill the power to idle EC cells.
The Latency Trade-Off
So what happens when a user clicks a file located on a Pin-3 disabled cell?
Just like with tape, HuskHoard relies on fanotify. The Linux kernel suspends the user's application. The Sidecar catches the request, realizes the target Cell is powered down, and drops the 3.3V signal on Pin 3.
The drives receive power. The logic boards boot up. The spindles begin to rotate. Because spinning up 6 drives simultaneously creates a massive power spike (inrush current), the sidecar utilizes staggered spin-up, waiting a few milliseconds between each drive.
To the end user, a 10-second delay on an old archive file feels perfectly normal—often indistinguishable from a slow network connection or a waking NAS. But on the backend, that 10-second trade-off allows enterprise IT to house massive disk arrays at a fraction of the historical energy footprint.
By blending the deep-freeze capability of Tape, the density of SMR, and the hardware-level power severing of Pin 3, HuskHoard is proving that active archives don't have to be environmental liabilities.