RAID Simulator

RAID simulator: fail a disk and watch what the controller actually does

This is a virtual backplane. You pick a RAID level, load virtual disks into it, send a read or a write, then click a disk to kill it and watch the array's state change in front of you — which columns in the stripe map go dark, whether the array stays online or drops offline, what happens to latency while it is degraded, and how a rebuild onto a spare puts it back. Nothing here touches real storage and nothing leaves your browser: the disks, the payloads, the cache and the controller log are all state in the page, cleared by the Reset button or by a refresh.

It is deliberately mechanical rather than statistical. If the question is what is the chance this array loses data over five years, that is a different tool. The question here is what happens, step by step, when this disk dies right now.

Eleven levels, including the ones nobody deploys

The level selector covers standard RAID 0 through 6 and the nested levels 0+1, 10, 50 and 60. RAID 2, 3 and 4 are included precisely because they are historical — they make the design pressures visible in a way RAID 5 does not, especially the dedicated-parity bottleneck that RAID 5 exists to solve.

Capacity is always computed from the smallest member, which is the answer to the perennial “I added a 4 TB drive to my 1 TB array and got nothing” question. Mix sizes in the simulator and the wasted space is visible immediately in the usable-versus-raw readout. The array supports up to 16 virtual disks; nested levels require an even count, and the disk-count selector greys out counts a level cannot express.

The stripe map: where data, parity and mirrors actually land

The stripe map draws several consecutive stripes as a grid of columns (one per disk) and rows (one per stripe), colouring each cell as data, parity, or mirror/Q. The placement is not decorative — it is the real layout rule for each level:

• RAID 3 and 4 park parity on the last disk for every stripe. Every single write in the array hits that one disk, which is the bottleneck those levels are remembered for.
• RAID 5 rotates the parity column by one position per stripe, spreading that load across every member. Watch the violet cell walk diagonally down the map as you send writes.
• RAID 6 rotates two parity columns, P and Q, one position apart.
• RAID 1 shows disk 0 as data and every other member as a mirror of it.
• RAID 10 alternates data and mirror by column — even columns data, odd columns their mirror — so the pairing is obvious.
• RAID 0+1 shows the first half of the array as data and the second half as the mirror of that whole stripe set. Put that next to RAID 10 and the failure-isolation difference stops being an abstraction.
• RAID 50 and 60 split the array in half and rotate parity independently inside each group.

Injecting a failure and reading the result

Click any disk to fail it; click again to restore it. The controller re-evaluates the array immediately and reports one of three states.

• Healthy — nothing down.
• Degraded — the array is still serving I/O, but reads that touch the dead member are being reconstructed from parity or from the surviving mirror copy. Failed columns in the stripe map are struck through.
• Array offline — more members are down than the layout can cover. Reads and writes are rejected outright and the log says so.

The interesting part is that “more than it can cover” is not a single number, and the simulator evaluates each family on its own rules. RAID 0 dies on any failure. RAID 5 survives exactly one. RAID 6 survives any two. RAID 1 stays up as long as one member survives, however wide the mirror. RAID 10 is evaluated pair by pair — it survives one failure in every pair, so four failures out of eight can be survivable while a specific two can be fatal. RAID 0+1 checks each half of the array: a failure in one half is survivable, a failure in both halves is not. RAID 50 and 60 count failures per group and allow one and two respectively.

Killing two disks in a RAID 10 and then trying the same two positions in a RAID 0+1 is the fastest way to understand why the two layouts are not interchangeable, and it takes about ten seconds here.

Rebuilding onto a spare

A failed disk in an array that is still online shows a “Rebuild on spare” button. Start it and the disk enters a rebuilding state with a progress bar, the controller log records a projected duration, and when it completes the log confirms redundancy is restored. The projection is derived from the replacement drive's capacity against a rebuild rate built from the array's media limits, the number of survivors and the level's write penalty — a wide fast array projects a shorter rebuild than a narrow slow one, which is the behaviour you want to be able to see.

Changing the RAID level on a populated array does not snap instantly either. It kicks off a reshape job with its own progress bar and projected duration, scaled by how much data is on the array, and blocks I/O and disk changes until it finishes. Live level migration being slow and disruptive is the point.

Latency, throughput, and the slowest disk in the array

Every virtual disk carries a media profile, and the array takes the minimum read speed, the minimum write speed and the maximum latency across its members. One slow member sets the pace for everyone.

The ceilings the tool displays are read = min read × active disks × read boost and write = min write × active disks / write penalty. Transfer latency is media latency + size / throughput, and while the array is degraded the result is multiplied by 1.8 to represent reconstruction work on the read path.

Worked example on the default array — four 1,000 GB SATA SSDs in RAID 5. Usable capacity is 3 × 1,000 GB = 3 TB against 4 TB raw. The write ceiling is 520 × 4 / 4 = 520 MB/s, and the read ceiling is 550 × 4 × 0.85 = 1,870 MB/s. A 256 MB write therefore takes 0.08 + (256 / 520) × 1000 ≈ 492 ms. Now fail one disk: three members remain, the write ceiling drops to 520 × 3 / 4 = 390 MB/s, the transfer becomes 0.08 + (256 / 390) × 1000 ≈ 656 ms, and the degraded multiplier takes it to roughly 1,182 ms. The array is still up. It is also more than twice as slow, which is the part that shows up as a user complaint rather than an alert.

Add a single 7,200 RPM HDD to that all-SSD array and the read ceiling collapses from 550 MB/s per member to 210 MB/s per member, because the minimum is what counts. This is the fastest available demonstration of why mixed-media arrays are a bad idea.

Watching real bytes stripe across the array

The payload injector takes either a virtual size in megabytes or a block of text you type. Type text and the tool encodes it as UTF-8, shows the exact byte count, splits it into fragments sized to the stripe and disk count, and displays each fragment labelled with the virtual disk it is heading for. Sending it animates the stripes filling in sequence. It is a small thing, but seeing your own sentence chopped into pieces and dealt out across columns makes striping concrete in a way a diagram does not.

Writes also consume capacity. Each write adds to the used space on every non-failed member according to the level — divided across the data columns for parity levels, replicated in full for a mirror — and a write that would exceed usable capacity is rejected with a log entry naming the ceiling. The utilisation bar and the telemetry panel (bytes written, bytes read, last latency, stripes completed) track it all.

The controller cache

Four cache modes are modelled, along with a cache size and a manual flush:

• None — every request goes to the array.
• Read — payload names are remembered, and a read of a cached name returns at a fraction of array latency.
• Write-through — the write populates the cache and still pays the full array latency, which is what makes it the safe-but-slow option.
• Write-back — the write is acknowledged from cache at a fraction of array latency, and the log labels it as an acknowledgement rather than a completion. The dirty data sits in cache until you flush.

A hit-rate counter tracks requests against hits. The write-back-versus-write-through trade — a large latency win in exchange for acknowledged writes that are not yet on disk — is visible in the numbers side by side, and the flush button is the manual version of the battery-backed flush a real controller performs.

Reading the controller log

Every action appends a timestamped, colour-coded entry, newest first: disks loaded and removed, failures injected, degraded evaluations, rebuild and reshape start and completion, writes rejected for capacity, I/O rejected because the array is offline, cache hits, write-back acknowledgements, flushes. Working through a scenario and then reading the log back is a decent way to rehearse an incident timeline before you have to write a real one.

What this tool does not do: it does not model unrecoverable read errors, drive failure rates, or the probability of losing data over time, and it does not compute a mean time to data loss. For those questions — particularly the URE risk that makes wide RAID 5 arrays of large drives a poor idea — use the raid-reliability-calculator. Here, every failure is one you chose to inject.