Understanding RAID: Consistency Checks, Hot Spare, Reconstruction, and Performance Strategies

RAID (Redundant Array of Independent Disks) provides fault tolerance by using redundant disk groups such as RAID 1, 5, 6, 10, 50, and 60, ensuring data integrity and continued operation when individual disks fail.

1 Consistency Check

For RAID levels with redundancy, the RAID controller can perform consistency checks by comparing data on each disk with its redundant counterpart. Inconsistencies trigger automatic repair attempts and error logging. RAID 0 lacks redundancy and therefore does not support consistency checks.

2 Hot Backup

The hot backup feature uses hot spares and emergency backup to replace failed disks automatically.

Hot Spare

A hot spare is an idle disk pre‑configured to replace a failed member disk automatically, after which the controller reconstructs the data onto the spare.

Hot spares must have equal or greater capacity than the member disks and match the media type and interface.

Global hot spare: shared by all RAID groups on the controller; multiple globals can be configured.

Local hot spare: dedicated to a specific RAID group; each group can have one or more locals.

Hot spares are only usable with redundant RAID levels (RAID 1, 5, 6, 10, 50, 60) and must replace a disk on the same controller.

Emergency Backup

If a RAID group with redundancy experiences a disk failure and no hot spare is assigned, any idle disk of sufficient capacity and matching type will automatically replace the failed disk and start reconstruction, preventing data loss.

3 RAID Reconstruction

When a disk fails, the controller can reconstruct the lost data onto a new disk. Reconstruction applies only to redundant RAID levels.

If a hot spare is available, it replaces the failed disk and reconstruction starts automatically; otherwise, reconstruction begins after a new disk is manually inserted.

The reconstruction rate (CPU usage) can be set from 0 % (run only when the system is idle) to 100 % (use all CPU resources). Users should adjust this setting based on system load.

4 Virtual Disk Read/Write Policies

Read Policy

Read Ahead : The controller pre‑fetches subsequent data into cache (options like “Always Read Ahead”, “Read Ahead”, “Ahead”). This reduces seek time but requires power‑loss protection.

No Read Ahead : Data is read only when requested, avoiding unnecessary cache usage.

Write Policy

Write Back : Data is first written to cache and later flushed to the disk, improving write throughput. Requires power‑loss protection.

Write Through : Data is written directly to the disk without caching, offering lower risk on power loss but slower performance.

Write Back with BBU : If a Battery Backup Unit (BBU) is present and healthy, the controller uses cache; otherwise it falls back to write‑through.

Write Back Enforce : Forces write‑back mode even when the controller lacks a functional capacitor.

5 Data Power‑Loss Protection

RAID controllers use high‑speed cache to accelerate writes, but data in cache is vulnerable to loss on sudden power failure. Supercapacitors can supply power to transfer cached data to NAND flash, preserving it.

The controller automatically calibrates supercapacitor charge levels through a three‑stage charge‑discharge cycle, temporarily switching to write‑through mode during calibration.

6 Disk Striping

Striping distributes I/O load across multiple disks, improving parallelism and throughput. It divides a continuous data stream into smaller chunks (stripes) written across disks.

Stripe width: number of disks participating in the stripe (e.g., 4 for a four‑disk group).

Group stripe size: total size of a stripe across the group (e.g., 1 MB).

Disk stripe size: size of each chunk on an individual disk (e.g., 64 KB).

7 Disk Mirroring

Applicable to RAID 1 and RAID 10, mirroring writes identical data to two disks, providing 100 % redundancy. If one disk fails, the other continues serving data without interruption, though it doubles hardware cost.

8 External Configuration

External configurations appear when a newly added disk contains RAID metadata, after a controller replacement, or after hot‑plugging a member disk. Administrators can import, delete, or retain these configurations based on the deployment scenario.

9 Disk Power‑Saving

The controller can spin down idle SAS/SATA disks to save energy. Disks and hot spares in standby are awakened when operations such as RAID creation, hot‑spare activation, or expansion occur.

10 Disk Pass‑Through (JBOD)

Enabling JBOD allows direct command pass‑through to attached disks without RAID abstraction, useful for OS installations or applications that need raw disk access.

For further reading on storage technologies, refer to related technical articles and whitepapers.