RAID Sandbox
An interactive sandbox for learning how RAID actually works — live at
raid-sandbox.dev.
Founding principle: the RAID level is not selected, it is derived. You compose
disks and primitives on a canvas, and the engine works out what you built — level,
capacity, fault tolerance, performance — plus how the data physically lands on the
disks, animated in write order.
What's in it
- Data layer — compose disks into arrays along two orthogonal axes (segmentation
⟂ redundancy), nest arrays into arrays. The recognizer names the result from the
shape of the tree, never from a label you picked: RAID 0/1/5/6/10/1E/50/60/100/51/61,
JBOD, and the nested distinction between RAID 10 and RAID 1+0 that most references conflate.
- Physical layer — wire up backplane, HBA, controller, PCIe bus, CPU, RAID engine
and OS to determine whether you built hardware, software, or fake RAID.
- Placement + animation — the stripe × disk grid, with parity rotating per the real
algorithms (left/right symmetric/asymmetric, near/far/offset), animated one block at a
time so you see the write order and parity landing after the data it is computed from.
- Challenge mode — requirement-satisfaction, not target-level: any topology meeting
the requirements wins.
- Knowledge base — the same material as reference pages, generated from the
data the sandbox itself reads: raid-sandbox.dev/kb.
Correctness
Layouts are anchored to the Linux md source (drivers/md/raid5.c, raid10.c), and the
golden tables are hand-derived from those rules, never dumped from the engine — a
golden table generated by the code under test only proves the code agrees with itself.
Stack
Vanilla JS, no build step, no framework. Domain data lives in data/*.yaml, parsed
in-browser with a vendored copy of js-yaml (no npm, see vendor/README.md).
Run it locally
No build step, but the app loads its data with fetch(), so it needs to be served —
opening index.html as a file:// URL will not load the data:
python3 -m http.server 8000
# then open http://localhost:8000/
Tests
bash .development/automation/test.sh # every headless suite — the same CI runs
node tests/model-perf.test.js # or one file at a time (tests/*.test.js)
A handful of suites validate the YAML data files directly and need python3 +
pyyaml: Node has no YAML parser, and the app itself must stay zero-dependency, so
those suites read the files with Python instead.
Browser-based pages (tests/*.test.html, tests/animator.demo.html) need the local
server above — drag-and-drop, the picker and the animation are browser-only by design.
The game itself is desktop-only (ADR-003): below 900px it shows a notice instead.
