RAID

This article is about the data storage technology. For other uses, see Raid (disambiguation).

RAID, an acronym for Redundant Array of Independent Disks (Changed from its original term Redundant Array of Inexpensive Disks), is a technology that provides increased storage functions and reliability through redundancy. This is achieved by combining multiple disk drive components into a logical unit, where data is distributed across the drives in one of several ways called "RAID levels". This concept was first defined by David A. Patterson, Garth A. Gibson, and Randy Katz at the University of California, Berkeley in 1987 as Redundant Arrays of Inexpensive Disks. Marketers representing industry RAID manufacturers later attempted to reinvent the term to describe a redundant array of independent disks as a means of dissociating a low-cost expectation from RAID technology.

RAID is now used as an umbrella term for computer data storage schemes that can divide and replicate data among multiple physical disk drives. The physical disks are said to be in a RAID array, which is addressed by the operating system as one single disk. The different schemes or architectures are named by the word RAID followed by a number (e.g., RAID 0, RAID 1). Each scheme provides a different balance between two key goals: increase data reliability and increase input/output performance.

Standard levels

Main article: Standard RAID levels

A number of standard schemes have evolved which are referred to as levels. There were five RAID levels originally conceived, but many more variations have evolved, notably several nested levels and many non-standard levels (mostly proprietary). RAID levels and their associated data formats are standardised by SNIA in the Common RAID Disk Drive Format (DDF) standard.

Following is a brief textual summary of the most commonly used RAID levels.

• RAID 0 (block-level striping without parity or mirroring) has no (or zero) redundancy. It provides improved performance and additional storage but no fault tolerance. Hence simple stripe sets are normally referred to as RAID 0. Any disk failure destroys the array, and the likelihood of failure increases with more disks in the array (at a minimum, catastrophic data loss is twice as likely compared to single drives without RAID). A single disk failure destroys the entire array because when data is written to a RAID 0 volume, the data is broken into fragments called blocks. The number of blocks is dictated by the stripe size, which is a configuration parameter of the array. The blocks are written to their respective disks simultaneously on the same sector. This allows smaller sections of the entire chunk of data to be read off the drive in parallel, increasing bandwidth. RAID 0 does not implement error checking, so any error is uncorrectable. More disks in the array means higher bandwidth, but greater risk of data loss.
• In RAID 1 (mirroring without parity or striping), data is written identically to multiple disks (a "mirrored set"). Although many implementations create sets of 2 disks, sets may contain 3 or more disks. Array provides fault tolerance from disk errors or failures and continues to operate as long as at least one drive in the mirrored set is functioning. With appropriate operating system support, there can be increased read performance, and only a minimal write performance reduction. Using RAID 1 with a separate controller for each disk is sometimes called duplexing.
• In RAID 2 (bit-level striping with dedicated Hamming-code parity), all disk spindle rotation is synchronized, and data is striped such that each sequential bit is on a different disk. Hamming-code parity is calculated across corresponding bits on disks and stored on one or more parity disks. Extremely high data transfer rates are possible.
• In RAID 3 (byte-level striping with dedicated parity), all disk spindle rotation is synchronized, and data is striped such that each sequential byte is on a different disk. Parity is calculated across corresponding bytes on disks and stored on a dedicated parity disk. Very high data transfer rates are possible.
• RAID 4 (block-level striping with dedicated parity) is identical to RAID 5 (see below), but confines all parity data to a single disk, which can create a performance bottleneck. In this setup, files can be distributed between multiple disks. Each disk operates independently which allows I/O requests to be performed in parallel, though data transfer speeds can suffer due to the type of parity. The error detection is achieved through dedicated parity and is stored in a separate, single disk unit.
• RAID 5 (block-level striping with distributed parity) distributes parity along with the data and requires all drives but one to be present to operate; drive failure requires replacement, but the array is not destroyed by a single drive failure. Upon drive failure, any subsequent reads can be calculated from the distributed parity such that the drive failure is masked from the end user. The array will have data loss in the event of a second drive failure and is vulnerable until the data that was on the failed drive is rebuilt onto a replacement drive. A single drive failure in the set will result in reduced performance of the entire set until the failed drive has been replaced and rebuilt.
• RAID 6 (block-level striping with double distributed parity) provides fault tolerance from two drive failures; array continues to operate with up to two failed drives. This makes larger RAID groups more practical, especially for high-availability systems. This becomes increasingly important as large-capacity drives lengthen the time needed to recover from the failure of a single drive. Single-parity RAID levels are as vulnerable to data loss as a RAID 0 array until the failed drive is replaced and its data rebuilt; the larger the drive, the longer the rebuild will take. Double parity gives time to rebuild the array without the data being at risk if a single additional drive fails before the rebuild is complete.

The following table provides an overview of the most important parameters of standard RAID levels. Space efficiency is given as an equation in terms of the number of drives, n, which results in a value between 0 and 1, representing the fraction of the sum of the drives' capacities that is available for use. For example, if three drives are arranged in RAID 3, this gives a space efficiency of 1−(1/3) = 0.66. If their individual capacities are 250 GB each, for a total of 750 GB over the three, the usable capacity under RAID 3 for data storage is 500 GB.

Level	Description	Minimum # of disks	Space Efficiency	Fault Tolerance	Read Benefit	Write Benefit	Image
RAID 0	Block-level striping without parity or mirroring.	2	1	0 (none)	nX	nX
RAID 1	Mirroring without parity or striping.	2	1/n	n−1 disks	nX	1X
RAID 2	Bit-level striping with dedicated Hamming-code parity.	3	1 − 1/n ⋅ log2(n-1)	RAID 2 can recover from 1 disk failure or repair corrupt data or parity when a corrupted bit's corresponding data and parity are good.	variable	variable
RAID 3	Byte-level striping with dedicated parity.	3	1 − 1/n	1 disk	(n−1)X	(n−1)X*
RAID 4	Block-level striping with dedicated parity.	3	1 − 1/n	1 disk	(n−1)X	(n−1)X*
RAID 5	Block-level striping with distributed parity.	3	1 − 1/n	1 disk	(n−1)X*	(n−1)X*
RAID 6	Block-level striping with double distributed parity.	4	1 − 2/n	2 disks	(n−2)X*	(n−2)X*

* - Assumes hardware is fast enough to support

Nested (hybrid) RAID

Main article: Nested RAID levels

In what was originally termed hybrid RAID, many storage controllers allow RAID levels to be nested. The elements of a RAID may be either individual disks or RAIDs themselves. Nesting more than two deep is unusual.

As there is no basic RAID level numbered larger than 9, nested RAIDs are usually unambiguously described by attaching the numbers indicating the RAID levels, sometimes with a "+" in between. The order of the digits in a nested RAID designation is the order in which the nested array is built: for RAID 1+0 first pairs of drives are combined into two or more RAID 1 arrays (mirrors), and then the resulting RAID 1 arrays are combined into a RAID 0 array (stripes). It is also possible to combine stripes into mirrors (RAID 0+1). The final step is known as the top array. When the top array is a RAID 0 (such as in RAID 10 and RAID 50) most vendors omit the "+", though RAID 5+0 is clearer.

• RAID 0+1: striped sets in a mirrored set ( minimum four disks; even number of disks) provides fault tolerance and improved performance but increases complexity.

The key difference from RAID 1+0 is that RAID 0+1 creates a second striped set to mirror a primary striped set. The array continues to operate with one or more drives failed in the same mirror set, but if drives fail on both sides of the mirror the data on the RAID system is lost.

• RAID 1+0: mirrored sets in a striped set (minimum four disks; even number of disks) provides fault tolerance and improved performance but increases complexity.

The key difference from RAID 0+1 is that RAID 1+0 creates a striped set from a series of mirrored drives. The array can sustain multiple drive losses so long as no mirror loses all its drives.

• RAID 5+1: mirrored striped set with distributed parity (some manufacturers label this as RAID 53).

Whether an array runs as RAID 0+1 or RAID 1+0 in practice is often determined by the evolution of the storage system. A RAID controller might support upgrading a RAID 1 array to a RAID 1+0 array on the fly, but require a lengthy offline rebuild to upgrade from RAID 1 to RAID 0+1. With nested arrays, sometimes the path of least disruption prevails over achieving the preferred configuration.

RAID Parity

Further information: [[:Parity bit]]

Many RAID levels employ an error protection scheme called "parity". Most use the simple XOR parity described in this section, but RAID 6 uses two separate parities based respectively on addition and multiplication in a particular Galois Field. XOR parity calculation is a widely used method in information technology to provide fault tolerance in a given set of data.

In Boolean logic, there is a principle called exclusive or (XOR), meaning "one or the other, but not neither or both." For example:

0 XOR 0 = 0

0 XOR 1 = 1

1 XOR 0 = 1

1 XOR 1 = 0

The XOR operator is central to how parity data is created and used within an array. It is used both for the protection of data, as well as for the recovery of missing data.

As an example, for a simple RAID made up of 6 hard disks (4 for data, 1 for parity, and 1 for use as hot spare), where each drive is capable of holding just a single byte worth of storage, an initial RAID configuration with random values written to each of our four data drives would look like:

Drive #1: 00101010 (Data)

Drive #2: 10001110 (Data)

Drive #3: 11110111 (Data)

Drive #4: 10110101 (Data)

Drive #5: -------- (Hot Spare)

Drive #6: -------- (Parity)

Every time data is written to the data drives, a parity value is calculated in order to be able to recover from a disk failure. To calculate the parity for this RAID, the XOR of each drive's data is calculated. The resulting value is the parity data.

00101010 XOR 10001110 XOR 11110111 XOR 10110101 = 11100110

The parity data "11100110" is then written to the dedicated parity drive:

Drive #1: 00101010 (Data)

Drive #2: 10001110 (Data)

Drive #3: 11110111 (Data)

Drive #4: 10110101 (Data)

Drive #5: -------- (Hot Spare)

Drive #6: 11100110 (Parity)

In order to restore the contents of a failed drive, e.g. Drive #3, the same XOR calculation is performed against all the remaining drives, substituting the parity value (11100110) in place of the missing/dead drive:

00101010 XOR 10001110 XOR 11100110 XOR 10110101 = 11110111

With the complete contents of Drive #3 recovered, the data is written to the hot spare, and the RAID can continue operating.

Drive #1: 00101010 (Data)

Drive #2: 10001110 (Data)

Drive #3: --Dead-- (Data)

Drive #4: 10110101 (Data)

Drive #5: 11110111 (Hot Spare)

Drive #6: 11100110 (Parity)

At this point the dead drive has to be replaced with a working one of the same size. When this happens, depending on implementation the new drive will either take over as a new hot spare drive on standby and the old one will continue to act as a regular drive of the array, or (as illustrated below) the original hot spare's contents are automatically copied to the new drive by the array controller, allowing the original hot spare to return to its original purpose as an emergency standby drive. The resulting array is identical to its pre-failure state:

Drive #1: 00101010 (Data)

Drive #2: 10001110 (Data)

Drive #3: 11110111 (Data)

Drive #4: 10110101 (Data)

Drive #5: -------- (Hot Spare)

Drive #6: 11100110 (Parity)

This same basic XOR principle applies to parity within RAID groups regardless of capacity or number of drives. As long as there are enough drives present to allow for an XOR calculation to take place, parity can be used to recover data from any single drive failure. (A minimum of three drives must be present in order for parity to be used for fault tolerance, since the XOR operator requires two operands, and a place to store the result.)

RAID 10 versus RAID 5 in Relational Databases

A common myth (and one which serves to illustrate the mechanics of proper RAID implementation) is that in all deployments, RAID 10 is inherently better for relational databases than RAID 5, due to RAID 5's need to recalculate and redistribute parity data on a per-write basis. [2]

While this may have been a hurdle in past RAID 5 implementations, the task of parity recalculation and redistribution within modern Storage Area Network (SAN) appliances is performed as a back-end process transparent to the host, not as an in-line process which competes with existing I/O. (i.e. the RAID controller handles this as a housekeeping task to be performed during a particular spindle's idle timeslices, so as not to disrupt any pending I/O from the host.) The "write penalty" inherent to RAID 5 has been effectively masked since the late 1990s by a combination of improved controller design, larger amounts of cache, and faster hard disks.

In the vast majority of enterprise-level SAN hardware, any writes which are generated by the host are simply acknowledged immediately, and destaged to disk on the back end when the controller sees fit from an efficiency standpoint to do so. From the host's perspective, an individual write to a RAID 10 volume is no faster than an individual write to a RAID 5 volume; A difference between the two only becomes apparent when write cache at the SAN controller level is overwhelmed, and the SAN appliance must reject or gate further write requests in order to allow write buffers on the controller to destage to disk. While rare, this generally indicates poor performance management on behalf of the SAN administrator, not a shortcoming of RAID 5 or RAID 10. SAN appliances generally service multiple hosts which compete both for controller cache and spindle time with one another. This contention is largely masked, in that the controller is generally intelligent and adaptive enough to maximize read cache hit ratios while also maximizing the process of destaging data from write cache.

The choice of RAID 10 versus RAID 5 for the purposes of housing a relational database will depend upon a number of factors (spindle availability, cost, business risk, etc.) but, from a performance standpoint, it depends mostly on the type of I/O that database can expect to see. For databases that are expected to be exclusively or strongly read-biased, RAID 10 is often chosen in that it offers a slight speed improvement over RAID 5 on sustained reads and sustained randomized writes. If a database is expected to be strongly write-biased, RAID 5 becomes the more attractive option, since RAID 5 does not suffer from the same write handicap inherent in RAID 10; all spindles in a RAID 5 can be utilized to write simultaneously, whereas only half the members of a RAID 10 can be used. [3] However, for reasons similar to what has eliminated the "read penalty" in RAID 5, the reduced ability of a RAID 10 to handle sustained writes has been largely masked by improvements in controller cache efficiency and disk throughput.

What causes RAID 5 to be slightly slower than RAID 10 on sustained reads is the fact that RAID 5 has parity data interleaved within normal data. For every read pass in RAID 5, there is a probability that a read head may need to traverse a region of parity data. The cumulative effect of this is a slight performance drop compared to RAID 10, which does not use parity, and therefore will never encounter a circumstance where data underneath a head is of no use. For the vast majority of situations, however, most relational databases housed on RAID 10 perform equally well in RAID 5. The strengths and weaknesses of each type only become an issue in atypical deployments, or deployments on overcommitted or outdated hardware.[4]

There are, however, other considerations which must be taken into account other than simply those regarding performance. RAID 5 and other non-mirror-based arrays offer a lower degree of resiliency than RAID 10 by virtue of RAID 10's mirroring strategy. In a RAID 10, I/O can continue even in spite of multiple drive failures. By comparison, in a RAID 5 array, any simultaneous failure involving greater than one drive will render the array itself unusable by virtue of parity recalculation being impossible to perform. For many, particularly in mission-critical environments with enough capital to spend, RAID 10 becomes the favorite as it provides the lowest level of risk.[5]

Additionally, the time required to rebuild data on a hot spare in a RAID 10 is significantly less than RAID 5, in that all the remaining spindles in a RAID 5 rebuild must participate in the process, whereas only the spindle being created and its mirror need to participate in RAID 10. This further increases the reliability advantage of RAID 10 over RAID 5 since the window during which a second disc failure could (if it was the mirror being used in recovery that failed) cause data loss is reduced.

Again, modern SAN design largely masks any performance hit while the RAID array is in a degraded state, by virtue of selectively being able to perform rebuild operations both in-band or out-of-band with respect to existing I/O traffic. Given the rare nature of drive failures in general, and the exceedingly low probability of multiple concurrent drive failures occurring within the same RAID array, the choice of RAID 5 over RAID 10 often comes down to the preference of the storage administrator, particularly when weighed against other factors such as cost, throughput requirements, and physical spindle availability. [6]

In short, the choice of RAID 5 versus RAID 10 involves a complicated mixture of factors. There is no one-size-fits-all solution, as the choice of one over the other must be dictated by everything from the I/O characteristics of the database, to business risk, to worst case degraded-state throughput, to the number and type of disks present in the array itself. Over the course of the life of a database, you may even see situations where RAID 5 is initially favored, but RAID 10 slowly becomes the better choice, and vice versa.

New RAID classification

In 1996, the RAID Advisory Board introduced an improved classification of RAID systems. It divides RAID into three types: Failure-resistant disk systems (that protect against data loss due to disk failure), failure-tolerant disk systems (that protect against loss of data access due to failure of any single component), and disaster-tolerant disk systems (that consist of two or more independent zones, either of which provides access to stored data).

The original "Berkeley" RAID classifications are still kept as an important historical reference point and also to recognize that RAID Levels 0-6 successfully define all known data mapping and protection schemes for disk. Unfortunately, the original classification caused some confusion due to assumption that higher RAID levels imply higher redundancy and performance. This confusion was exploited by RAID system manufacturers, and gave birth to the products with such names as RAID-7, RAID-10, RAID-30, RAID-S, etc. The new system describes the data availability characteristics of the RAID system rather than the details of its implementation.

The next list provides criteria for all three classes of RAID:

- Failure-resistant disk systems (FRDS) (meets a minimum of criteria 1–6):

1. Protection against data loss and loss of access to data due to disk drive failure
2. Reconstruction of failed drive content to a replacement drive
3. Protection against data loss due to a "write hole"
4. Protection against data loss due to host and host I/O bus failure
5. Protection against data loss due to replaceable unit failure
6. Replaceable unit monitoring and failure indication

- Failure-tolerant disk systems (FTDS) (meets a minimum of criteria 7–15 ):

7. Disk automatic swap and hot swap
8. Protection against data loss due to cache failure
9. Protection against data loss due to external power failure
10. Protection against data loss due to a temperature out of operating range
11. Replaceable unit and environmental failure warning
12. Protection against loss of access to data due to device channel failure
13. Protection against loss of access to data due to controller module failure
14. Protection against loss of access to data due to cache failure
15. Protection against loss of access to data due to power supply failure

- Disaster-tolerant disk systems (DTDS) (meets a minimum of criteria 16–21):

16. Protection against loss of access to data due to host and host I/O bus failure
17. Protection against loss of access to data due to external power failure
18. Protection against loss of access to data due to component replacement
19. Protection against loss of data and loss of access to data due to multiple disk failure
20. Protection against loss of access to data due to zone failure
21. Long-distance protection against loss of data due to zone failure

Non-standard levels

Main article: Non-standard RAID levels

Many configurations other than the basic numbered RAID levels are possible, and many companies, organizations, and groups have created their own non-standard configurations, in many cases designed to meet the specialised needs of a small niche group. Most of these non-standard RAID levels are proprietary.

• Storage Computer Corporation used to call a cached version of RAID 3 and 4, RAID 7. Storage Computer Corporation is now defunct.
• EMC Corporation used to offer RAID S as an alternative to RAID 5 on their Symmetrix systems. Their latest generations of Symmetrix, the DMX and the V-Max series, do not support RAID S (instead they support RAID 1, RAID 5 and RAID 6.)
• The ZFS filesystem, available in Solaris, OpenSolaris and FreeBSD, offers RAID-Z, which solves RAID 5's write hole problem.
• Hewlett-Packard's Advanced Data Guarding (ADG) is a form of RAID 6.
• NetApp's Data ONTAP uses RAID-DP (also referred to as "double", "dual", or "diagonal" parity), is a form of RAID 6, but unlike many RAID 6 implementations, does not use distributed parity as in RAID 5. Instead, two unique parity disks with separate parity calculations are used. This is a modification of RAID 4 with an extra parity disk.
• Accusys Triple Parity (RAID TP) implements three independent parities by extending RAID 6 algorithms on its FC-SATA and SCSI-SATA RAID controllers to tolerate three-disk failure.
• Linux MD RAID10 (RAID 10) implements a general RAID driver that defaults to a standard RAID 1 with 2 drives, and a standard RAID 1+0 with four drives, but can have any number of drives, including odd numbers. MD RAID 10 can run striped and mirrored, even with only two drives with the f2 layout (mirroring with striped reads, giving the read performance of RAID 0; normal Linux software RAID 1 does not stripe reads, but can read in parallel).
• Infrant (now part of Netgear) X-RAID offers dynamic expansion of a RAID 5 volume without having to back up or restore the existing content. Just add larger drives one at a time, let it resync, then add the next drive until all drives are installed. The resulting volume capacity is increased without user downtime. (It should be noted that this is also possible in Linux, when utilizing Mdadm utility. It has also been possible in the EMC Clariion and HP MSA arrays for several years.) The new X-RAID2 found on x86 ReadyNas, that is ReadyNas with Intel CPUs, offers dynamic expansion of a RAID 5 or RAID 6 volume (note X-RAID2 Dual Redundancy not available on all X86 ReadyNas) without having to back up or restore the existing content etc. A major advantage over X-RAID, is that using X-RAID2 you do not need to replace all the disks to get extra space, you only need to replace two disks using single redundancy or four disks using dual redundancy to get more redundant space.
• BeyondRAID, created by Data Robotics and used in the Drobo series of products, implements both mirroring and striping simultaneously or individually dependent on disk and data context. It offers expandability without reconfiguration, the ability to mix and match drive sizes and the ability to reorder disks. It supports NTFS, HFS+, FAT32, and EXT3 file systems. It also uses thin provisioning to allow for single volumes up to 16 TB depending on the host operating system support.
• Hewlett-Packard's EVA series arrays implement vRAID - vRAID-0, vRAID-1, vRAID-5, and vRAID-6. The EVA allows drives to be placed in groups (called Disk Groups) that form a pool of data blocks on top of which the RAID level is implemented. Any Disk Group may have "virtual disks" or LUNs of any vRAID type, including mixing vRAID types in the same Disk Group - a unique feature. vRAID levels are more closely aligned to Nested RAID levels - vRAID-1 is actually a RAID 1+0 (or RAID 10), vRAID-5 is actually a RAID 5+0 (or RAID 50), etc. Also, drives may be added on-the-fly to an existing Disk Group, and the existing virtual disks data is redistributed evenly over all the drives, thereby allowing dynamic performance and capacity growth.
• IBM (Among others) has implemented a RAID 1E (Level 1 Enhanced). With an even number of disks it is similar to a RAID 10 array, but, unlike a RAID 10 array, it can also be implemented with an odd number of drives. In either case, the total available disk space is n/2. It requires a minimum of three drives.
• Hadoop has a RAID system that generates a parity file by xor-ing a stripe of blocks in a single HDFS file.

Data backup

A RAID system used as a main system disk is not intended as a replacement for backing up data. In parity configurations it will provide a backup-like feature to protect from catastrophic data loss caused by physical damage or errors on a single drive. Many other features of backup systems cannot be provided by RAID arrays alone. The most notable is the ability to restore an earlier version of data, which is needed to protect against software errors causing unwanted data to be written to the disk, and to recover from user error or malicious deletion. RAID can also be overwhelmed by catastrophic failure that exceeds its recovery capacity and, of course, the entire array is at risk of physical damage by fire, natural disaster, or human forces. RAID is also vulnerable to controller failure since it is not always possible to migrate a RAID to a new controller without data loss.

RAID drives can serve as excellent backup drives when employed as removable backup devices to main storage, and particularly when located offsite from the main systems. However, the use of RAID as the only storage solution does not replace backups.

Implementations

The distribution of data across multiple drives can be managed either by dedicated hardware or by software. When done in software the software may be part of the operating system or it may be part of the firmware and drivers supplied with the card.

Software-based RAID

Software RAID implementations are now provided by many operating systems. Software RAID can either be implemented as a layer that abstracts multiple devices providing a single virtual device (e.g. Linux's md), as a more generic logical volume manager (provided with most server-class operating systems, e.g. Veritas or LVM), or as a component of the file system (e.g. ZFS or btrfs).

Volume manager support

Server class operating systems typically provide logical volume management, which allows a system to use logical volumes which can be resized or moved. Often, features like RAID or snapshots are also supported.

• Vinum is a logical volume manager supporting RAID-0, RAID-1 and RAID-5. Vinum is part of the base distribution of the FreeBSD operating system, and versions exist for NetBSD, OpenBSD and DragonFly BSD.
• Solaris SVM supports RAID 1 for the boot filesystem, and adds RAID 0 and RAID 5 support (and various nested combinations) for data drives.
• Linux LVM supports RAID 0 and RAID 1.
• HP's OpenVMS provides a form of RAID 1 called "Volume shadowing", giving the possibility to mirror data locally and at remote cluster systems.

File system support

Some advanced file systems can be distributed over multiple devices.

• ZFS supports ZFS equivalents of RAID 0, RAID 1, RAID 5 (RAID Z), RAID 6 (RAID Z2), and a triple parity version RAID Z3, and any nested combination of those like 1+0. ZFS is the native file system on Solaris, and also available on FreeBSD and Linux.
• Btrfs supports RAID 0, RAID 1, and RAID 10.

Other support

Many operating systems provide basic RAID functionality independently of volume management.

• Apple's Mac OS X Server and Mac OS X support RAID 0, RAID 1 and RAID 1+0.
• FreeBSD supports RAID 0, RAID 1, RAID 3, and RAID 5 and all layerings of the above via GEOM modules and ccd.
• Linux's md supports RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 and all layerings of the above, as well as "RAID10" (see above) . Certain reshaping/resizing/expanding operations are also supported.
• Microsoft's server operating systems support RAID 0, RAID 1, and RAID 5. Some of the Microsoft desktop operating systems support RAID such as Windows XP Professional which supports RAID level 0 in addition to spanning multiple disks but only if using dynamic disks and volumes. Windows XP can be modified to support RAID 0, 1, and 5.
• NetBSD supports RAID 0, RAID 1, RAID 4 and RAID 5 (and any nested combination of those like 1+0) via its software implementation, named RAIDframe.
• OpenBSD aims to support RAID 0, RAID 1, RAID 4 and RAID 5 via its software implementation softraid.
• Linux and Windows FlexRAID is a snapshot RAID implementation.

Software RAID has advantages and disadvantages compared to hardware RAID. The software must run on a host server attached to storage, and server's processor must dedicate processing time to run the RAID software. The additional processing capacity required for RAID 0 and RAID 1 is low, but parity-based arrays require more complex data processing during write or integrity-checking operations. As the rate of data processing increases with the number of disks in the array, so does the processing requirement. Furthermore all the buses between the processor and the disk controller must carry the extra data required by RAID which may cause congestion.

Over the history of hard disk drives, the increase in speed of commodity CPUs has been consistently greater than the increase in speed of hard disk drive throughput. Thus, over-time for a given number of hard disk drives, the percentage of host CPU time required to saturate a given number of hard disk drives has been dropping. e.g. The Linux software md RAID subsystem is capable of calculating parity information at 6 GB/s (100% usage of a single core on a 2.1 GHz Intel "Core2" CPU as of Linux v2.6.26). A three-drive RAID 5 array using hard disks capable of sustaining a write of 100 MB/s will require parity to be calculated at the rate of 200 MB/s. This will require the resources of just over 3% of a single CPU core during write operations (parity does not need to be calculated for read operations on a RAID 5 array, unless a drive has failed).

Software RAID implementations may employ more sophisticated algorithms than hardware RAID implementations (for instance with respect to disk scheduling and command queueing), and thus may be capable of increased performance.

Another concern with operating system-based RAID is the boot process. It can be difficult or impossible to set up the boot process such that it can fall back to another drive if the usual boot drive fails. Such systems can require manual intervention to make the machine bootable again after a failure. There are exceptions to this, such as the LILO bootloader for Linux, loader for FreeBSD, the NetBSD boot loader and some configurations of the GRUB bootloader natively understand RAID 1 and can load a kernel. If the BIOS recognizes a broken first disk and refers bootstrapping to the next disk, such a system will come up without intervention, but the BIOS might or might not do that as intended. A hardware RAID controller typically has explicit programming to decide that a disk is broken and fall through to the next disk.

Hardware RAID controllers can also carry battery-powered cache memory. For data safety in modern systems the user of software RAID might need to turn the write-back cache on the disk off (but some drives have their own battery/capacitors on the write-back cache, a UPS, and/or implement atomicity in various ways, etc.). Turning off the write cache has a performance penalty that can, depending on workload and how well supported command queuing in the disk system is, be significant. The battery backed cache on a RAID controller is one solution to have a safe write-back cache.

Finally operating system-based RAID usually uses formats specific to the operating system in question so it cannot generally be used for partitions that are shared between operating systems as part of a multi-boot setup. However, this allows RAID disks to be moved from one computer to a computer with an operating system or file system of the same type, which can be more difficult when using hardware RAID (e.g. #1: When one computer uses a hardware RAID controller from one manufacturer and another computer uses a controller from a different manufacturer, drives typically cannot be interchanged. e.g. #2: If the hardware controller 'dies' before the disks do, data may become unrecoverable unless a hardware controller of the same type is obtained, unlike with firmware-based or software-based RAID).

Most operating system-based implementations allow RAIDs to be created from partitions rather than entire physical drives. For instance, an administrator could divide an odd number of disks into two partitions per disk, mirror partitions across disks and stripe a volume across the mirrored partitions to emulate IBM's RAID 1E configuration. Using partitions in this way also allows mixing reliability levels on the same set of disks. For example, one could have a very robust RAID 1 partition for important files, and a less robust RAID 5 or RAID 0 partition for less important data. (Some BIOS-based controllers offer similar features, e.g. Intel Matrix RAID.) Using two partitions on the same drive in the same RAID is, however, dangerous. (e.g. #1: Having all partitions of a RAID 1 on the same drive will, obviously, make all the data inaccessible if the single drive fails. e.g. #2: In a RAID 5 array composed of four drives 250 + 250 + 250 + 500 GB, with the 500 GB drive split into two 250 GB partitions, a failure of this drive will remove two partitions from the array, causing all of the data held on it to be lost).

Hardware-based RAID

Hardware RAID controllers use different, proprietary disk layouts, so it is not usually possible to span controllers from different manufacturers. They do not require processor resources, the BIOS can boot from them, and tighter integration with the device driver may offer better error handling.

A hardware implementation of RAID requires at least a special-purpose RAID controller. On a desktop system this may be a PCI expansion card, PCI-e expansion card or built into the motherboard. Controllers supporting most types of drive may be used – IDE/ATA, SATA, SCSI, SSA, Fibre Channel, sometimes even a combination. The controller and disks may be in a stand-alone disk enclosure, rather than inside a computer. The enclosure may be directly attached to a computer, or connected via SAN. The controller hardware handles the management of the drives, and performs any parity calculations required by the chosen RAID level.

Most hardware implementations provide a read/write cache, which, depending on the I/O workload, will improve performance. In most systems the write cache is non-volatile (i.e. battery-protected), so pending writes are not lost on a power failure.

Hardware implementations provide guaranteed performance, add no overhead to the local CPU complex and can support many operating systems, as the controller simply presents a logical disk to the operating system

Firmware/driver-based RAID

Operating system-based RAID does not always protect the boot process and is generally impractical on desktop versions of Windows (as described above). Hardware RAID controllers are expensive and proprietary. To fill this gap, cheap "RAID controllers" were introduced that do not contain a RAID controller chip, but simply a standard disk controller chip with special firmware and drivers. During early stage bootup the RAID is implemented by the firmware; when a protected-mode operating system kernel such as Linux or a modern version of Microsoft Windows is loaded the drivers take over.

These controllers are described by their manufacturers as RAID controllers, and it is rarely made clear to purchasers that the burden of RAID processing is borne by the host computer's central processing unit, not the RAID controller itself, thus introducing the aforementioned CPU overhead from which hardware controllers do not suffer. Firmware controllers often can only use certain types of hard drives in their RAID arrays (e.g. SATA for Intel Matrix RAID), as there is neither SCSI nor PATA support in modern Intel ICH southbridges; however, motherboard makers implement RAID controllers outside of the southbridge on some motherboards. Before their introduction, a "RAID controller" implied that the controller did the processing, and the new type has become known by some as "fake RAID" even though the RAID itself is implemented correctly. Adaptec calls them "HostRAID". Various Linux distributions will refuse to work with "fake RAID".[7].

Network-attached storage

Main article: Network-attached storage

While not directly associated with RAID, Network-attached storage (NAS) is an enclosure containing disk drives and the equipment necessary to make them available over a computer network, usually Ethernet. The enclosure is basically a dedicated computer in its own right, designed to operate over the network without screen or keyboard. It contains one or more disk drives; multiple drives may be configured as a RAID.

Hot spares

Both hardware and software RAIDs with redundancy may support the use of hot spare drives, a drive physically installed in the array which is inactive until an active drive fails, when the system automatically replaces the failed drive with the spare, rebuilding the array with the spare drive included. This reduces the mean time to recovery (MTTR), though it does not eliminate it completely. Subsequent additional failure(s) in the same RAID redundancy group before the array is fully rebuilt can result in loss of the data; rebuilding can take several hours, especially on busy systems.

Rapid replacement of failed drives is important as the drives of an array will all have had the same amount of use, and may tend to fail at about the same time rather than randomly. RAID 6 without a spare uses the same number of drives as RAID 5 with a hot spare and protects data against simultaneous failure of up to two drives, but requires a more advanced RAID controller. Further, a hot spare can be shared by multiple RAID sets.

Reliability terms

Failure rate

Two different kinds of failure rates are applicable to RAID systems. Logical failure is defined as the loss of a single drive and its rate is equal to the sum of individual drives' failure rates. System failure is defined as loss of data and its rate will depend on the type of RAID. For RAID 0 this is equal to the logical failure rate, as there is no redundancy. For other types of RAID, it will be less than the logical failure rate, potentially approaching zero, and its exact value will depend on the type of RAID, the number of drives employed, and the vigilance and alacrity of its human administrators.

Mean time to data loss (MTTDL)

In this context, the average time before a loss of data in a given array. Mean time to data loss of a given RAID may be higher or lower than that of its constituent hard drives, depending upon what type of RAID is employed. The referenced report assumes times to data loss are exponentially distributed. This means 63.2% of all data loss will occur between time 0 and the MTTDL.

Mean time to recovery (MTTR)

In arrays that include redundancy for reliability, this is the time following a failure to restore an array to its normal failure-tolerant mode of operation. This includes time to replace a failed disk mechanism as well as time to re-build the array (i.e. to replicate data for redundancy).

Unrecoverable bit error rate (UBE)

This is the rate at which a disk drive will be unable to recover data after application of cyclic redundancy check (CRC) codes and multiple retries.

Write cache reliability

Some RAID systems use RAM write cache to increase performance. A power failure can result in data loss unless this sort of disk buffer is supplemented with a battery to ensure that the buffer has enough time to write from RAM back to disk.

Atomic write failure

Also known by various terms such as torn writes, torn pages, incomplete writes, interrupted writes, non-transactional, etc.

Problems with RAID

Correlated failures

The theory behind the error correction in RAID assumes that failures of drives are independent. Given these assumptions it is possible to calculate how often they can fail and to arrange the array to make data loss arbitrarily improbable.

In practice, the drives are often the same age, with similar wear, and subject to the same environment. Since many drive failures are due to mechanical issues which are more likely on older drives, this violates those assumptions and failures are in fact statistically correlated. In practice then, the chances of a second failure before the first has been recovered is not nearly as unlikely as might be supposed, and data loss can, in practice, occur at significant rates.

A common misconception is that "server-grade" drives fail less frequently than consumer-grade drives. Two independent studies, one by Carnegie Mellon University and the other by Google, have shown that the "grade" of the drive does not relate to failure rates.

Atomicity

This is a little understood and rarely mentioned failure mode for redundant storage systems that do not utilize transactional features. Database researcher Jim Gray wrote "Update in Place is a Poison Apple" during the early days of relational database commercialization. However, this warning largely went unheeded and fell by the wayside upon the advent of RAID, which many software engineers mistook as solving all data storage integrity and reliability problems. Many software programs update a storage object "in-place"; that is, they write a new version of the object on to the same disk addresses as the old version of the object. While the software may also log some delta information elsewhere, it expects the storage to present "atomic write semantics," meaning that the write of the data either occurred in its entirety or did not occur at all.

However, very few storage systems provide support for atomic writes, and even fewer specify their rate of failure in providing this semantic. Note that during the act of writing an object, a RAID storage device will usually be writing all redundant copies of the object in parallel, although overlapped or staggered writes are more common when a single RAID processor is responsible for multiple drives. Hence an error that occurs during the process of writing may leave the redundant copies in different states, and furthermore may leave the copies in neither the old nor the new state. The little known failure mode is that delta logging relies on the original data being either in the old or the new state so as to enable backing out the logical change, yet few storage systems provide an atomic write semantic on a RAID disk.

While the battery-backed write cache may partially solve the problem, it is applicable only to a power failure scenario.

Since transactional support is not universally present in hardware RAID, many operating systems include transactional support to protect against data loss during an interrupted write. Novell Netware, starting with version 3.x, included a transaction tracking system. Microsoft introduced transaction tracking via the journaling feature in NTFS. Ext4 has journaling with checksums; ext3 has journaling without checksums but an "append-only" option, or ext3COW (Copy on Write). If the journal itself in a filesystem is corrupted though, this can be problematic. The journaling in NetApp WAFL file system gives atomicity by never updating the data in place, as does ZFS. An alternative method to journaling is soft updates, which are used in some BSD-derived system's implementation of UFS.

This can present as a sector read failure. Some RAID implementations protect against this failure mode by remapping the bad sector, using the redundant data to retrieve a good copy of the data, and rewriting that good data to the newly mapped replacement sector. The UBE (Unrecoverable Bit Error) rate is typically specified at 1 bit in 10¹⁵ for enterprise class disk drives (SCSI, FC, SAS) , and 1 bit in 10¹⁴ for desktop class disk drives (IDE/ATA/PATA, SATA). Increasing disk capacities and large RAID 5 redundancy groups have led to an increasing inability to successfully rebuild a RAID group after a disk failure because an unrecoverable sector is found on the remaining drives. Double protection schemes such as RAID 6 are attempting to address this issue, but suffer from a very high write penalty.

Write cache reliability

The disk system can acknowledge the write operation as soon as the data is in the cache, not waiting for the data to be physically written. This typically occurs in old, non-journaled systems such as FAT32, or if the Linux/Unix "writeback" option is chosen without any protections like the "soft updates" option (to promote I/O speed whilst trading-away data reliability). A power outage or system hang such as a BSOD can mean a significant loss of any data queued in such a cache.

Often a battery is protecting the write cache, mostly solving the problem. If a write fails because of power failure, the controller may complete the pending writes as soon as restarted. This solution still has potential failure cases: the battery may have worn out, the power may be off for too long, the disks could be moved to another controller, the controller itself could fail. Some disk systems provide the capability of testing the battery periodically, however this leaves the system without a fully charged battery for several hours.

An additional concern about write cache reliability exists, specifically regarding devices equipped with a write-back cache—a caching system which reports the data as written as soon as it is written to cache, as opposed to the non-volatile medium. The safer cache technique is write-through, which reports transactions as written when they are written to the non-volatile medium.

Equipment compatibility

The methods used to store data by various RAID controllers are not necessarily compatible, so that it may not be possible to read a RAID array on different hardware, with the exception of RAID 1, which is typically represented as plain identical copies of the original data on each disk. Consequently a non-disk hardware failure may require the use of identical hardware to recover the data, and furthermore an identical configuration has to be reassembled without triggering a rebuild and overwriting the data. Software RAID however, such as implemented in the Linux kernel, alleviates this concern, as the setup is not hardware dependent, but runs on ordinary disk controllers, and allows the reassembly of an array. Additionally, individual RAID1 disks (software, and most hardware implementations) can be read like normal disks when removed from the array, so no RAID system is required to retrieve the data. Inexperienced data recovery firms typically have a difficult time recovering data from RAID drives, with the exception of RAID1 drives with conventional data structure.

Data recovery in the event of a failed array

With larger disk capacities the odds of a disk failure during rebuild are not negligible. In that event the difficulty of extracting data from a failed array must be considered. Only RAID 1 stores all data on each disk. Although it may depend on the controller, some RAID 1 disks can be read as a single conventional disk. This means a dropped RAID 1 disk, although damaged, can often be reasonably easily recovered using a software recovery program. If the damage is more severe, data can often be recovered by professional data recovery specialists. RAID 5 and other striped or distributed arrays present much more formidable obstacles to data recovery in the event the array fails.

Drive error recovery algorithms

Many modern drives have internal error recovery algorithms that can take upwards of a minute to recover and re-map data that the drive fails to easily read. Many RAID controllers will drop a non-responsive drive in 8 seconds or so. This can cause the array to drop a good drive because it has not been given enough time to complete its internal error recovery procedure, leaving the rest of the array vulnerable. So-called enterprise class drives limit the error recovery time and prevent this problem, but desktop drives can be quite risky for this reason. A fix specific to Western Digital drives used to be known: a utility called WDTLER.exe could limit the error recovery time of a Western Digital desktop drive so that it would not be dropped from the array for this reason. The utility enabled TLER (time limited error recovery) which limits the error recovery time to 7 seconds. As of October 2009 Western Digital has locked out this feature in their desktop drives such as the Caviar Black. Western Digital enterprise class drives are shipped from the factory with TLER enabled to prevent being dropped from RAID arrays. Similar technologies are used by Seagate, Samsung, and Hitachi.

As of late 2010, support for ATA Error Recovery Control configuration has been added to the Smartmontools program, so it now allows configuring many desktop class hard drives for use on a RAID controller.

Increasing recovery time

Drive capacity has grown at a much faster rate than transfer speed, and error rates have only fallen a little in comparison. Therefore, larger capacity drives may take hours, if not days, to rebuild. The re-build time is also limited if the entire array is still in operation at reduced capacity. Given a RAID array with only one disk of redundancy (RAIDs 3, 4, and 5), a second failure would cause complete failure of the array. Even though individual drives' mean time between failure (MTBF) have increased over time, this increase has not kept pace with the increased storage capacity of the drives. The time to rebuild the array after a single disk failure, as well as the chance of a second failure during a rebuild, have increased over time.

Operator skills, correct operation

In order to provide the desired protection against physical drive failure, a RAID array must be properly set up and maintained by an operator with sufficient knowledge of the chosen RAID configuration, array controller (hardware or software), failure detection and recovery. Unskilled handling of the array at any stage may exacerbate the consequences of a failure, and result in downtime and full or partial loss of data that might otherwise be recoverable.

Particularly, the array must be monitored, and any failures detected and dealt with promptly. Failure to do so will result in the array continuing to run in a degraded state, vulnerable to further failures. Ultimately more failures may occur, until the entire array becomes inoperable, resulting in data loss and downtime. In this case, any protection the array may provide merely delays this.

The operator must know how to detect failures or verify healthy state of the array, identify which drive failed, have replacement drives available, and know how to replace a drive and initiate a rebuild of the array.

Other problems

While RAID may protect against physical drive failure, the data is still exposed to operator, software, hardware and virus destruction. Many studies cite operator fault as the most common source of malfunction, such as a server operator replacing the incorrect disk in a faulty RAID array, and disabling the system (even temporarily) in the process. Most well-designed systems include separate backup systems that hold copies of the data, but do not allow much interaction with it. Most copy the data and remove the copy from the computer for safe storage.

In low end small RAID systems, RAID5 has issues that make it of debatable utility. Low-end means using on-board RAID controllers on the motherboard, which use Windows or host OS drivers for the rebuilding. This means that if the host OS is on a RAID5 array controlled via a motherboard chip, and a drive fails, the entire RAID5 array is lost. The only remedy is to attach the degraded array to a higher-cost hardware RAID5 controller that with luck, is compatible and able to rebuild the array.

History

Norman Ken Ouchi at IBM was awarded a 1978 U.S. patent 4,092,732 titled "System for recovering data stored in failed memory unit." The claims for this patent describe what would later be termed RAID 5 with full stripe writes. This 1978 patent also mentions that disk mirroring or duplexing (what would later be termed RAID 1) and protection with dedicated parity (that would later be termed RAID 4) were prior art at that time.

The term RAID was first defined by David A. Patterson, Garth A. Gibson and Randy Katz at the University of California, Berkeley, in 1987. They studied the possibility of using two or more drives to appear as a single device to the host system and published a paper: "A Case for Redundant Arrays of Inexpensive Disks (RAID)" in June 1988 at the SIGMOD conference.

This specification suggested a number of prototype RAID levels, or combinations of drives. Each had theoretical advantages and disadvantages. Over the years, different implementations of the RAID concept have appeared. Most differ substantially from the original idealized RAID levels, but the numbered names have remained. This can be confusing, since one implementation of RAID 5, for example, can differ substantially from another. RAID 3 and RAID 4 are often confused and even used interchangeably.

One of the early uses of RAID 0 and 1 was the Crosfield Electronics Studio 9500 page layout system based on the Python workstation. The Python workstation was a Crosfield managed international development using PERQ 3B electronics, benchMark Technology's Viper display system and Crosfield's own RAID and fibre-optic network controllers. RAID 0 was particularly important to these workstations as it dramatically sped up image manipulation for the pre-press markets. Volume production started in Peterborough, England in early 1987.

Non-RAID drive architectures

Main article: Non-RAID drive architectures

Non-RAID drive architectures also exist, and are often referred to, similarly to RAID, by standard acronyms, several tongue-in-cheek. A single drive is referred to as a SLED (Single Large Expensive Drive), by contrast with RAID, while an array of drives without any additional control (accessed simply as independent drives) is referred to as a JBOD (Just a Bunch Of Disks). Simple concatenation is referred to as a SPAN, or sometimes as JBOD, though this latter is proscribed in careful use, due to the alternative meaning just cited.

See also

• Disk array controller
• Redundant Array of Inexpensive Nodes
• Stable storage
• Hard drives
• Disk array
• Storage area network (SAN)

Further reading

• Charles M. Kozierok (2001-04-17). "Redundant Arrays of Inexpensive Disks". The PC Guide. Pair Networks.
• RAID Level 2

External links

• Template:Dmoz