Linux with Operating System Concepts

RAID levels
. The levels 
differ from each other such that the levels do not progressively improve upon the prior 
level. There are seven commonly cited RAID levels (although not all are used) along with 
two “combined” levels and a hybrid level. Table 14.1 provides a comparison between all 
the RAID levels. We will concentrate on two different RAID approaches that are found in 
RAID 1 and RAIDs 3–6.
RAID level 1 provides a complete mirror of your storage space. Let us imagine that you 
are using file servers for disk storage. Every user’s home directory is stored on a file server. 
If this file server uses RAID 1, then every time the user stores some data, they are stored 
twice, once to one set of disks and once to a second set. Should one set of disks ever fail, the 
data are still available and can be restored easily. The mirror might be implemented inside 
one cabinet, or alternatively, the mirror may be a separate file server located elsewhere.
A nice side effect of the mirror is to support multiple disk accesses simultaneously. 
Specifically, two read accesses could take place at the same time, one from one set of disks 

---

574
◾
Linux with Operating System Concepts
and one from the mirror. However, if one access involves a write, then a second access 
would not be permitted simultaneously because the write must involve both sets.
RAID levels 3–6 use parity information to record redundancy. This requires a brief 
explanation. Let us imagine that we have the following four bytes of information to store, 
each of which is stored on a separate disk.
TABLE 14.1 
RAID Levels
Level
Description
Advantages/Disadvantages
Usage
0
Striping at block level, no 
redundancy
A: Improved disk performance over 
standard disk drive
D: No redundancy
For superior disk 
performance without 
redundancy, where 
increased cost is not a 
concern
1
Complete mirror
A: Provides 100% redundancy and 
improves disk access for parallel reads
D: Most costly form of RAID
Safest form of RAID if 
cost is not a factor
2
Striping at bit level, 
redundancy through 
Hamming codes
A: Fast access for single-disk operation
D: Hamming codes are time consuming 
to compute
Not used in practice 
because of Hamming 
codes
3
Striping at byte level, 
parity bit redundancy
A: Fast access for single-disk operation, 
compromise between expense and 
redundancy
D: All drives active for any single access; 
so, cannot accommodate parallel 
accesses
Useful for single user 
systems
4
Striping at block level, 
single-parity disk
A: Larger stripes accommodate parallel 
accesses (like RAID 0) but improve over 
RAID 0 because of redundancy
D: Single-parity disk is a bottleneck 
defeating advantage gained by striping
Not used in practice 
because the parity disk is 
a bottleneck
5
Striping at block level, 
parity distributed 
across disks
A: Same as 4
D: None
Useful for multiuser 
systems (e.g., file 
servers)
6
Striping at block level, 
parity distributed across 
disks and duplicated
A: Same as 4 and 5 except that with 
double the parity information, it 
provides a greater degree of redundancy
D: More expensive than RAIDs 3–5
Same as 5
7
RAID 3 (or 4) with 
real-time operating 
system controller
A: Faster single-disk access over RAID 3
D: More expensive
Same as 3
10
Striping at block level, 
complete mirror (RAID 
0 and RAID 1 combined)
A: Same as 0 and 1 combined
D: Requires twice as much disk drive as 
RAID 1
For file servers that 
require both parallel disk 
access and redundancy
53
Extra disks to support 
RAID 3 and RAID 5 
striping
A: Best overall access as one can access 
the RAID 3 or the RAID 5 set of disks
D: Requires more disks and so is more 
expensive than 3 or 5
Useful for multiuser 
systems (e.g., file 
servers)
S
Proprietary form of 
RAID 5 with high-speed 
disk cache
A: Improves over RAID 5 access
D: More expensive than RAID 5
Useful for multiuser 
systems (e.g., file 
servers)

---

Maintaining and Troubleshooting Linux
◾
575
00000000
11110000
10101010
00101111
To compute the parity information, we will use the XOR Boolean operation on the 4 
bits of each column (i.e., we will XOR the first bit of each of the 4 bytes, we will XOR the 
second bit of each of the 4 bytes, etc.). XOR can be applied to implement an even parity 
computation. Even parity means that the number of 1 bit in the sequence will always be an 
even number. We will perform the following operation given four bits, b0, b1, b2, and b3:
(b0 XOR b1) XOR (b2 XOR b3)
For the first column, we would compute
(0 XOR 1) XOR (1 XOR 0) 
=
1 XOR 1 
=
0
So, our first parity bit will be 0. For the second column, we have
(0 XOR 1) XOR (0 XOR 0) 
=
1 XOR 0 
=
1
For the third column, we have
(0 XOR 1) XOR (1 XOR 1) 
=
1 XOR 0 
=
1
The entire parity byte for our four bytes above is computed as shown below.
00000000
11110000
10101010
00101111
--------
01110101
We store the parity information on a separate disk. So, in this case, we would have five 
disks, the first four storing data, and the fifth storing parity. Should a disk block fail on any 
of the five drives, we have enough information to restore it by using XOR on the surviving 
data. In fact, with this approach, we could restore data if we lost an entire disk. We could 
even restore data lost when multiple disks fail as long as the failures are of different bytes 
(RAID 3) or blocks (RAID 4–6).
In Figure 14.1, we see an illustration of a RAID drive. There are five disk drives, each 
with four surfaces. Let us assume that a disk block’s data are stored on four of the sur-
faces with the parity information on a fifth surface where each block is stored on the same 

---

576
◾
Linux with Operating System Concepts
location of different drives. For instance, we might find all five blocks of a file on track 32, 
sector 7, and surface 1 on the five drives. In the figure, we see that this RAID drive contains 
three failed blocks (denoted as black rectangles). Since the bad blocks are not of the 
same
track and sector, the bad blocks are of different file blocks. Therefore, for any bad block, 
four other blocks are not bad, allowing us to restore the bad block from the other four. It 
does not matter whether the bad block is of original data or parity data.
Unfortunately, what RAID will not save us from is a complete failure of many disks. 
Even RAID 1, with its complete mirror, would not help if we lost both sides of the mirror. 
So, while RAID is a solution to promote redundancy and provide some protection from 
data loss, it is not necessarily the best solution. We should still perform backups. However, 
with RAID available, we may be able to get away with less frequent backups. Additionally, 
the combination of RAID and backups provide us with a more flexible means of ensuring 
data integrity and availability. This is discussed in Section 14.6.
14.2.3 Backup Strategies
Now that we have decided to perform backups, we should also explore how long a backup 
should be saved. Imagine that you back up some partition every day. You use magnetic tape 
for each backup. You save each day on a separate tape and each week, you recycle the tapes. 
You take each day’s backup and move it to a separate location (e.g., a safe, or some off-site 
location). This seems more than satisfactory because you are backing up daily and you have 
the data held securely.
But consider this situation. A user deletes a file. Two weeks later, the user realizes that 
he wants the file back. He cannot reclaim it from the backups because the backups only 
cover the previous week. Should backups be retained for a longer period of time? We will 
attempt to answer this with a strategy in the following paragraphs. Notice that there is a 
difference between saving data for