Articles
RAID Interview Questions: Usable Capacity, Failure Sets, and Rebuild Risk
Practice RAID capacity calculations, RAID10 failure combinations, degraded reads, and rebuild estimates with explicit disk, layout, and recovery assumptions.
“RAID 10 can survive multiple disk failures” is an incomplete interview answer. Two failed disks can leave every block readable or destroy one mirror pair. The result depends on where the failures occur, which copies or parity information remain, and whether recovery finishes before another fault exposes missing data.
For RAID interview questions, calculate usable capacity under explicit assumptions, enumerate the allowed failure sets, and treat rebuild as a period of reduced protection. This guide uses original eight-disk exercises rather than an employer-specific question list. Official implementation facts are linked when introduced; candidate reports do not establish interview frequency or a universal recovery procedure.
Practice connecting durability to application behavior with Design an Object Storage Service With Buckets, Keys and Durable Blob Storage, then return to the disk-level guarantees below.
What assumptions come before a RAID capacity calculation?
Official overview: Red Hat's RAID documentation distinguishes striping, mirroring, and parity-based levels. RAID 0 stripes without redundancy; RAID 1 mirrors; RAID 5 and RAID 6 provide one and two parity blocks per stripe, respectively. RAID 10 combines mirroring and striping. These mechanisms explain the level names; an exact capacity answer still needs the component sizes and layout.
For our original model, use eight equal 8 TB disks. TB means decimal terabytes. All disks are active members, except when an exercise explicitly reserves a spare. Ignore filesystem overhead, array metadata, alignment, and reserved capacity. “Usable” in this table therefore means nominal array data capacity, not the space an application will ultimately see.
| Stated layout | Nominal data capacity | Complete-disk failure guarantee in the model |
|---|---|---|
| RAID 0 across eight disks | 64 TB | No disk failure tolerated |
| RAID 1, one eight-way mirror | 8 TB | Readable with any one intact copy |
| RAID 5 across eight disks | 56 TB | Any one failed member |
| RAID 6 across eight disks | 48 TB | Any two failed members |
| RAID 10, four two-disk mirror pairs | 32 TB | Any one failure; additional failures depend on pairs |
Explain the unusual RAID 1 row: eight copies of the same logical data are one eight-way mirror. Four separate two-disk mirrors provide four logical volumes unless another layer combines them. They are not the same capacity arrangement simply because all eight physical disks are mirrored somewhere.
If the interviewer says one disk is a hot spare, remove it from the active-member count before calculating parity capacity. For seven active 8 TB disks plus one spare, RAID 5 has nominal capacity 48 TB. The spare is replacement capacity, not an additional active data member. It can reduce the delay before reconstruction starts; it does not add another parity equation.
Why does RAID 10 survive some two-disk failures?
Specify the pair placement:
Pair A: D0, D1
Pair B: D2, D3
Pair C: D4, D5
Pair D: D6, D7
The original model stripes data across these four pairs. It survives a failure set only if every pair retains at least one readable member. Failure of D0 and D2 is survivable because D1 and D3 retain those pairs' data. Failure of D0 and D1 removes both copies from Pair A and makes part of the logical array unavailable.
There are choose(8,2) = 28 distinct two-disk failure sets. Four are complete mirror pairs; the other 24 leave a copy in every pair. Thus 24 of 28 combinations survive under this layout and clean whole-disk failure model. This count is not an estimate of real-world failure probability: faults need not be uniformly distributed or independent.
Four simultaneous failures can also be survivable if exactly one member fails from every pair. There are 2^4 = 16 such sets among choose(8,4) = 70 possible four-disk sets. The phrase “can survive four failures” describes a best-case arrangement, not a four-failure guarantee.
Turn the claim into a test rather than memorizing it:
pairs = [{0, 1}, {2, 3}, {4, 5}, {6, 7}]
def survives(failed):
return all(not pair.issubset(failed) for pair in pairs)
Enumerate combinations and check both a surviving cross-pair set and a fatal same-pair set. This is a teaching model, not an implementation of every controller or Linux MD RAID 10 layout. Before transferring the answer to a real system, inspect how that implementation places copies.
What happens to reads when an array is degraded?
A degraded array has lost part of its intended redundancy. That does not automatically mean every read fails. In a mirror, the surviving copy can serve data. In a parity layout, some reads can use an intact data block directly, while reads needing missing data require reconstruction from other stripe information.
Distinguish foreground reads from rebuild work. A successful application read proves that requested data was served at that moment. It does not prove that all stripes are readable, the remaining members are healthy, or redundancy has been restored. An untouched unreadable sector may surface only when recovery scans the relevant area.
For an interview scenario, assume D0 fails in our four-pair RAID 10. The array can still read Pair A through D1 under the clean-failure assumptions. During replacement, copying Pair A's data relies on D1. Losing D2 also is not immediately fatal because D3 survives, but it exposes a second pair to a single remaining copy. Losing D1 before Pair A is reconstructed breaks the model's readability condition.
Use this reasoning to describe risk in terms of exposed data sets. “Seven disks remain” does not state which blocks still have a copy. Draw the failed members on the pair map before interpreting the remaining disk count.
How long will an 8 TB rebuild take?
For a bounded arithmetic exercise, assume the replacement must receive 8 TB of reconstructed data at a constant 100 MB/s effective rebuild rate. Use decimal units consistently:
8,000,000 MB / 100 MB/s = 80,000 seconds
80,000 / 3,600 ≈ 22.2 hours
This is an idealized estimate under the stated effective rate. A vendor's sequential peak bandwidth does not establish the effective rebuild rate. Foreground traffic, controller limits, recovery throttling, small random reads, error retries, and changing disk throughput can all change elapsed time.
Keep a separate read-volume ledger. Rebuilding one failed member of a two-copy mirror can read its surviving partner's data. In an explicitly assumed full-stripe reconstruction of an eight-member RAID 5, reading 8 TB from each of seven survivors means 56 TB of aggregate survivor reads to reconstruct an 8 TB member. Actual implementations and used-space optimizations may perform different work; the example is not a universal I/O formula.
The important distinction is target bytes versus total recovery work. A replacement disk writing at a reasonable rate does not establish whether surviving disks or the controller are overloaded. Ask for observed progress, survivor I/O, foreground latency, errors, and the configured recovery policy before predicting completion.
If the effective rate falls to 50 MB/s, the 8 TB idealized transfer takes about 44.4 hours. If it fluctuates, extrapolate cautiously from a recent sustained interval and disclose the measurement window. A single early percentage cannot guarantee the remaining duration.
Does an unreadable sector mean the whole array is lost?
Do not turn a sector-level fault into a universal whole-array outcome. A disk can remain present while a particular read fails. Whether affected data can be reconstructed depends on the stripe's surviving information, the RAID level, and implementation behavior. Application impact can range from recoverable errors to loss of particular blocks or an unavailable array.
For a simplified RAID 5 stripe with one missing data block, the remaining parity equation can reconstruct that block if the required surviving information is readable. If another required block in that stripe becomes unavailable, one equation no longer determines both missing values. This establishes an information deficit for that stripe; it does not by itself establish that every other stripe vanished.
RAID 6 adds another independent parity relation, but it does not make recovery unlimited. State the fault set and remaining readable information. Do not equate a device's advertised unrecoverable-read specification with the probability that any particular rebuild will lose the entire array. Such a probability model would need justified assumptions about bytes read, error dependence, workload, and the meaning of the specification.
Correlated faults matter as a planning inference. Shared power, controller paths, enclosure failures, and similar device histories can defeat an independence assumption. A mirror placement diagram should therefore include physical failure domains when the question asks for protection from more than individual disk faults.
How do writes and array state complicate recovery?
Capacity and parity equations assume coherent stored information. A crash during writes introduces another question: which data and parity updates reached durable storage? Controller cache protection, ordering, journaling or other consistency mechanisms, and the actual filesystem contract affect the answer.
Official Linux MD behavior: the kernel RAID documentation describes array states and warns about dirty, degraded parity arrays, where missing data and untrusted parity can prevent reliable reconstruction. It also exposes recovery and consistency information through sysfs. Do not describe forcing assembly as a routine way to make data safe; making an array start and proving its contents correct are different outcomes.
In an interview incident, begin with evidence. The mdadm manual documents information-gathering operations such as detailed array inspection. A Linux example might collect:
cat /proc/mdstat
mdadm --detail /dev/md0
These commands illustrate inspection of an already-existing array. Confirm the actual device identity and implementation. Examine member roles, failed members, spare activation, synchronization progress, and recent I/O errors before proposing a change. Hardware controllers expose different interfaces; do not invent Linux output for them.
Our exercises perform arithmetic and failure-set enumeration only. No physical disk was failed, array assembled, or operational rebuild executed for this guide. That boundary keeps the examples useful without presenting a simulator as operational recovery evidence.
Why is RAID not a backup strategy?
Redundancy retains data across certain component failures. It does not supply an independent earlier version after a mistaken deletion, bad application write, compromised credentials, or a site-wide event that affects all members. A mirror can preserve an incorrect write on both copies.
Define the desired recovery outcome separately: how much recent data may be lost, how quickly service must return, and which failure domains the recovery copy must survive. Then ask whether backups are independently accessible and whether restores have been tested. A green backup-job status is weaker evidence than a successful restore of the required data and application state.
For the eight-disk exercise, choose a layout based on the specified workload, capacity, and failure guarantee. Then explain the additional recovery plan. A strong answer does not claim RAID 6 always wins or RAID 10 always performs better; it identifies which assumptions could change the choice.