Why RAID Exists: Objectives, Architecture, and Fault Model

RAID exists because ordinary disks do not meet every storage goal by themselves. As explained in Chapter 38 and 44(1) (1), when we use a disk, we want it to be faster, larger, and more reliable. Individual disk I/O can be slow enough to become a system bottleneck, storage needs continue to grow, and disk failures can cause total data loss if data is not protected. RAID, which stands for Redundant Array of Inexpensive Disks, addresses these needs by using multiple disks together as one storage system.

Why storage systems use RAID

According to Chapter 38 and 44(1) (1), RAID is a technique that uses multiple disks in concert to build a storage system that is:

• Faster by allowing multiple disks to participate in servicing requests.
• Bigger by combining the capacity of several disks.
• More reliable by storing redundant information so data can survive some failures.

The source also shows that different RAID organizations emphasize these goals differently. For example, RAID 0 improves performance and capacity by striping data across disks, but it has no redundancy. RAID 1 improves reliability by keeping multiple copies of each block. Parity-based RAIDs save more space than mirroring while still providing recovery from certain disk failures.

Performance, capacity, and reliability trade-offs

Chapter 38 and 44(1) (1) makes clear that RAID is not just about reliability; it is also about balancing several storage objectives.

• Performance: Striping spreads blocks across disks in a round-robin fashion so contiguous requests can be served in parallel. This helps large sequential access patterns.
• Capacity: Using many disks together creates a larger logical storage space than a single disk can provide.
• Reliability: Mirroring and parity allow the system to continue operating correctly despite some disk failures.

The slides also note that these goals can conflict. For example, RAID 0 provides an excellent upper bound on performance and capacity, but because it has no redundancy, it does not improve reliability. Mirroring improves fault tolerance, but it consumes extra space because each logical block has more than one physical copy. Thus, RAID exists because storage systems need a practical way to navigate these trade-offs.

The external RAID interface

Externally, a RAID is designed to look simple. Chapter 38 and 44(1) (1) states that a RAID looks like a disk: a group of blocks that can be read or written. This disk-like abstraction is important because it lets a host system use the RAID without needing to understand its internal complexity.

In other words, the host issues logical I/O requests as if it were talking to a single disk. The RAID hides how those requests are actually carried out across multiple physical drives.

The internal RAID architecture

Although the external view is simple, the internal design is much more complex. Chapter 38 and 44(1) (1) explains that RAID systems often contain:

• Multiple physical disks that store data and redundancy.
• A microcontroller running firmware to direct RAID operations.
• Volatile memory such as DRAM to buffer blocks during reads and writes.
• Sometimes non-volatile memory to buffer writes safely.
• A standard host connection, such as SCSI or SATA, so the RAID can present itself to the computer like a normal disk device.

This internal organization is what allows RAID to transform one logical request into multiple physical operations. The source gives a mirroring example: if the RAID keeps two copies of each block on separate disks, then one logical write may require two physical I/Os. This shows the key architectural idea of RAID: the user sees one disk-like device, while internally the RAID coordinates many disks and extra control logic.

How RAID reasons about failures

To design RAID correctly, the system must assume a particular kind of fault behavior. Chapter 38 and 44(1) (1) says RAID is designed to detect and recover from certain kinds of disk faults, so knowing what faults to expect is critical.

The basic fault model emphasized in the source is the fail-stop fault model.

The fail-stop disk fault model

In the fail-stop model, a disk is assumed to be in exactly one of two states:

• Working — all blocks can be read or written.
• Failed — the disk has stopped functioning.

This model is useful because it simplifies reasoning about RAID behavior. If a disk is working, RAID can trust normal reads and writes to that disk. If a disk fails, RAID uses redundancy such as mirroring or parity to recover data or continue operation.

The fail-stop model is therefore a foundation for understanding classic RAID levels. Mirrored systems can survive a disk failure because another copy exists. Parity-based systems can reconstruct lost data by reading the remaining data blocks and parity information.

Why the fault model matters

The choice of fault model affects RAID design. Under fail-stop assumptions, RAID mechanisms can be built around a straightforward question: what happens if one disk stops working entirely? This is why redundancy methods such as:

• duplicate copies in mirroring, and
• XOR-based parity in parity RAID levels

are effective in the classic RAID discussion in Chapter 38 and 44(1) (1). They are designed to recover from complete disk loss, not just to improve speed or combine capacity.

The later data integrity slides in the same source also show that real storage systems worry about additional problems such as latent sector errors and corruption. However, the fail-stop disk model is the core starting point used to reason about traditional RAID behavior.

Summary

RAID exists because storage systems want more than a single disk can easily provide. As presented in Chapter 38 and 44(1) (1), RAID uses multiple disks together to improve:

• Performance through parallel access,
• Capacity through aggregation of disks, and
• Reliability through redundancy.

Externally, RAID presents a simple disk-like block interface. Internally, it contains multiple disks, a controller, firmware, and memory that coordinate the work needed to turn logical requests into physical I/O operations. To reason about failure handling, RAID commonly uses the fail-stop fault model, where a disk is either fully working or fully failed. This model helps explain why classic RAID techniques such as striping, mirroring, and parity are organized the way they are.