For a while we haven’t reviewed RAID controllers from HighPoint (we tested the RocketRAID 2320 about two years ago) and Promise. Now that we resumed controller testing in our labs we decided to take one SATA RAID controller from each brand’s lineup. HighPoint was represented by the RocketRAID 3220. That’s not the best but far not the weakest model in the company’s line-up. At the HighPoint website it is positioned as an enterprise-level product. Its opponent has similar capabilities: the SuperTrak EX8350 belongs to the latest series of controllers from Promise that support SATA drives only.
The HighPoint RocketRAID 3220 is equipped with a PCI-X interface that was considered a de-facto standard for controllers of its class some time ago, but the Promise SuperTrak EX8350 is equipped with PCI Express that is steadily occupying the market. This occupation should have been expected, though. PCI Express provides higher bandwidth (when using all the 16 lanes). The recently released second version of the PCI Express standard doubles the data-transfer rate, ensuring redundant bandwidth even. As for PCI-X, its bandwidth may be insufficient for multi-disk arrays built out of modern HDDs. PCI Express is also more appealing for mainboard makers. Its slot is smaller and its wiring is simpler. No wonder then that it has become popular not only as the interface for graphics cards but also as a peripheral interface on server mainboards. So, this review is going to be our last in which we will talk about a PCI-X controller unless some manufacturer suddenly releases a very interesting model with it.
What makes this review special is that we will test the controllers not only in ordinary operation modes (with one to four disks in JBOD, RAID0, 1, 10, 5 and 6) but also in degraded mode (degraded RAID5 and RAID6), i.e. when one or two disks in the array fail. We didn’t tear a drive out of the operating array, we just shut it down. There are three such modes in this test session: a RAID5 array with one disabled disk and a RAID6 with one or two disabled disks. The latter situation is most unlikely, but if RAID6 can work in such mode, we must check it out, too.
You may wonder if it makes any sense to test RAID arrays in such extraordinary operating modes. If one or two disks in the array fail, it is time to run to the nearest shop searching for a replacement disk! Well, some equipment cannot be just shut down in case of a failure. Many servers operate on a 24/7 basis and shutting them down for maintenance may lead to a serious financial loss. And if you choose RAID6 for its ability to go on working even when two of its disks fail, it must work well without them until your IT department replaces the disks. As the old joke goes, “In a corporation employing tens of thousands people, someone dies daily but it shouldn’t be the reason for halting the work every time it happens.”
So what happens with a degraded array? It’s all right at writing: the controller pretends the array is okay, but the data that should be written to the failed disk is not written at all. Of course, there is nothing wrong in this because checksums are still created for each stripe, and the information written this way can be read afterwards. When the disk is replaced, all the information can be restored using a standard algorithm. There is no need to find out which part of the written information is full and requires redistribution and which part of it requires restoration.
When it comes to reading from a degraded array, the controller has to cope with additional load: the data that was stored on the missing HDD has to be restored basing on checksums each time it is read. It doesn’t sound as terrible as it really is. In fact, the controller must read a full stripe with the missing data and restore the data using the XOR operation. Therefore the performance of a degraded array is not the same as the performance of a same-type array originally built out of the same amount of disks minus one.
When the failed disk is replaced, the RAID controller has an especially difficult time. Besides ordinary operations, it has to fill the new disk with the data that must be stored on the latter. That is, the controller must browse through the whole bulk of data, restoring missing data out of checksums and writing checksums anew to the replacement disk. Of course, you can’t expect the controller to perform fast under such a heavy load. Well, we are merciful in our tests and limit ourselves to checking the load the controller has to cope with when there are failed disks in the array, but not under the array restoration load. After all, you can always choose a time period when the load on the array is the lowest to perform the restoration. As opposed to that, the failure of a disk happens accidentally and, usually, in the most inappropriate moment.
The next section will give you more information about the controllers we are going to test today.