Research notes / Archival storage
Sleeping disks: one readable block is not a recoverable array
17 October 2026 / Paper review and exhaustive algebraic check
A read can succeed without waking its disk even when the active disks cannot reconstruct all data. The distinction is exact, testable and easy to lose behind a count of parity disks.
Treat sleep as temporary unavailability
Greenan and colleagues proposed using redundancy to avoid disk activation. Their HotDep 2008 paper studies flat codes, with one symbol per disk. It presents analytical examples, not a modern fleet energy benchmark; CPU and network energy are outside its accounting. [1]
The five-data/three-parity construction is:
s5 = s0 XOR s1 XOR s2
s6 = s0 XOR s1 XOR s3
s7 = s0 XOR s2 XOR s3 XOR s4With disks 0, 5, 6 and 7 active, XOR cancels the repeated inputs:
s4 = s0 XOR s5 XOR s6 XOR s7
- s0Active
- s1Sleeping, ambiguous
- s2Sleeping, ambiguous
- s3Sleeping, ambiguous
- s4Sleeping, derivable
- s5Active
- s6Active
- s7Active
Check every input, not one convenient value
Hesela enumerates all 32 binary input words for this code and all 16 for the paper's four-data/four-parity example. For each of 256 active-disk subsets, it groups codewords by their visible symbols. A target is recoverable only if every codeword with the same observation agrees on that target. Since XOR operates independently on each bit, the conclusion extends to equal-length blocks under these equations.
A second test enumerates XOR combinations of the available coefficient vectors. Agreement between both checks guards against confusing a readable target with a uniquely decodable full input.
| Code | Full-data recovery | Non-recoverable pairs |
|---|---|---|
| 5 data + 3 parity | 27 / 28 | s4 and s7 |
| 4 data + 4 parity | 28 / 28 | None |
If s4 and s7 are unavailable in the first construction, changing only input s4 changes no visible symbol. Two different data words therefore fit the same observation. No decoder can resolve that ambiguity without additional information.
These are finite combinatorial counts, not 27/28 and 28/28 field reliability probabilities. No distribution over failures or sleep states is assumed. The second code also stores fewer data symbols in the same eight disks. Neither row alone establishes a better storage system.
MAID results need their workload attached
Colarelli and Grunwald's 2002 MAID study used trace-driven simulation, calibrated with drive measurements. Its reported archival workload had little locality: adding cache drives worsened response time. Figure 5 reports roughly 15-16% of baseline drive energy, not a datacenter-wide saving. The abstract's 1/15 wording conflicts with that figure; do not silently equate them. [2, sections 2-5]
That historical result does not select an idle timer for a present deployment. A useful evaluation must include request deadlines, transition energy, maintenance reads, parity freshness, failure recovery and total-system power. A nearline HDD product label specifies none of that policy.
Reproduce and keep the boundary explicit
Download the MIT-licensed JavaScript module, complete JSON result and tests. Run the tests with Node.js; call buildResults() for all 512 states. The generator receipt records the runtime and source hash. This is an algebraic reproduction, not a recreation of either paper's energy experiments.
Every available symbol is assumed correct, current and part of the same completed codeword. Stale parity, undetected corruption, interrupted updates, spin-up failures and overlapping requests are outside the model. A sleeping disk can return; a permanently lost disk cannot. Treating both as unavailable for one observation does not make their durability consequences equal.
Corpus: MAID and power-aware coding. Related: local repair costs.
Primary sources
- Kevin M. Greenan, Darrell D. E. Long, Ethan L. Miller, Thomas J. E. Schwarz and Jay J. Wylie. A Spin-Up Saved is Energy Earned: Achieving Power-Efficient, Erasure-Coded Storage. HotDep 2008, sections 2-6.
- Dennis Colarelli and Dirk Grunwald. Massive Arrays of Idle Disks For Storage Archives. SC 2002, July 26 manuscript, sections 2-5 and 7.