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.
- 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.
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.
Vanilla JS, no build step, no framework. Domain data lives in data/*.yaml.
Headless suites run under plain node, one file at a time:
node tests/model-perf.test.js # and the other tests/*.test.jsBrowser-based pages (tests/*.test.html, tests/animator.demo.html) need a local
server — the responsive, touch and accordion behaviour is browser-only by design.