Navigate: Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home	.	.
Prices: Mainboards ABIT ASUS Chaintech Shuttle Soyo Tyan CPU Intel P4 2.4C-800 P4 2.6C-800 P4 2.8C-800 P4 3.0-800 P4 3.2-800 AMD AthlonXP XP 1700+ XP 2000+ XP 2400+ XP 2500+ XP 2700+ XP 3000+ XP 3200+ Athlon64 Athlon64 3200+ Athlon64 FX-51 Opteron Opteron 240 Opteron 242 Opteron 244 Opteron 246 Memory Corsair Crucial Kingston Mushkin OCZ Search Prices:

The RAID Cache

Many RAID controllers use substantial amounts of SDRAM to alleviate performance bottlenecks that can arise on writes. That is, the data are not directly written to the drives but to a dedicated memory module or discreet component from which they are then processed and forwarded to the individual drives. The reason is that RAID Level5 or any other level involving parity calculations are notoriously slow when it comes to writing data to the array, moreover, there is a substantial amount of computation involved as we showed above, that can interfere with other system processes.

One issue that can arise from RAID cache using SDRAM is that this type of memory is volatile, meaning that in case of a sudden loss of power data that have not yet been written to the platter can be lost. The workaround in this case is relatively simple in that any battery can be used to keep SDRAM in autorefresh mode, which suffices to prevent data loss while running at extremely low power consumption.

Write Hole

Another issue with RAID levels that use parity is the problem of the write hole. The write hole is the time between writing a set of data to one of the drives within the array and the time it takes to update the parity data. In other words, if a loss of power or any other catastrophic system failure occurs after the data have been written to the media but before the parity data have been updated, the result will be that the parity no longer matches the data. For correct storage of data under all conditions, it is therefore necessary to have a record keeping mechanism in place that “journals” the status of all write transactions and, therefore, after e.g. a power loss, will be able to tell that the data are correct and that the parity will need to be updated accordingly. Needless to say that such journal has to be updated with every transaction and further has to retain data independent of any environmental conditions. The latter condition is matched by a number of non-volatile memory solutions, the cheapest of which is Flash memory, which, however, does not meet the endurance requirements. Therefore, other non-volatile memory solutions such as FRAM or nvSRAM with practically unlimited endurance are much better suited, albeit slightly more expensive.

Screenshot from a White Paper on the write hole on the Zzyzx website, illustrating the vulnerable period of time.

Conclusion

This article was only meant to provide a brief overview over the different RAID solutions and some of the issues that are involved, predominantly, the entire concept of parity and error checking and correction along with the intriguing fact that ECC can be used to add redundancy without inflating the storage space requirements. One issue we deliberately left out of this article is the entire field of performance, RAID Levels 2,3 and 4 are hardly used at all anymore and RAID Level5 performance depends on quite a few issues that go beyond the drives used or the controllers, especially when it comes to writing data. In software parity solutions, raw CPU power is the predominant feature, along with the PCI bandwidth since the shuffling of data through the PCI bus to the CPU and back occupies incredible amounts of system resources.

In other words, it appears not only the load on the processor itself but also the bus occupancy that favor a dedicated "RAID" parity processor on either a PCI card or on the mainboard, integrated as a local device. Side effects that we observed were the mouse freezing during each HDD write, particularly with a PS/2 mouse. USB mice were not affected as strongly but it is not the purpose of this article to elaborate on the compatibiliy of one or the other device with the HighPoint 1640 controller card, rather, we want to give a few brief examples of what can and will happen in soft RAID Level5 implementations, simply by the nature of the issues involved.

next page:    => More =>