Appendix A: Optimizing RAID 5 Write Performance
Introduction
With a typical RAID 5 implementation, there are a number of steps necessary to write the data to the media. Every write from the host system will typically generate two XOR operations and their associated data transfers to two drives. If the accesses are sequential, the parity information will be updated a number of times in succession. However, if the host writes sufficient data to cover a complete stripe, the parity data does not need to be updated for each write. It can be recalculated instead. This operation takes only one XOR operation per host write, compared to two for a standard RAID 5 write. The number of data transfers necessary are also reduced, increasing the available bandwidth. This type of write access is termed a Full Stripe Write.
P | C20 | C21 | C22 | C23 | Stripe 5 |
|
|
|
|
|
|
C16 | C17 | C18 | C19 | P | Stripe 4 |
|
|
|
|
|
|
C12 | C13 | C14 | P | C15 | Stripe 3 |
|
|
|
|
|
|
C8 | C9 | P | C10 | C11 | Stripe 2 |
|
|
|
|
|
|
C4 | P | C5 | C6 | C7 | Stripe 1 |
|
|
|
|
|
|
P | C0 | C1 | C2 | C3 | Stripe 0 |
|
|
|
|
|
|
The table shows the distribution of data chunks (denoted by Cx) and their associated parity (denoted by
Maximum performance will be achieved when all drives are performing multiple commands in parallel. To take advantage of a Full Stripe Write, the host has to send enough data to the controller. This can be accomplished in two ways. If the host sends one command with sufficient data to fill a stripe, then the controller can perform a Full Stripe Write. Alternatively, if the host sends multiple sequential commands, smaller than a stripe size (typically matching the chunk size), the controller can internally combine these commands to get the same effect. In the above example, if a 256 K chunk size
228 | www.gateway.com |