Affordable storage for the SME, part one

Latency and Further Analyses

So let us delve a bit deeper in our SQLIO benchmarking. What kind of latency may we expect with these systems? In many cases latency (seek time + 1/2 rotation) will be the bottleneck. To understand the behavior of our different storage system better we tested with both a 2GB and 20GB file.


Bandwidth doesn't really get any lower when you access the hard disk sequentially in our configuration. This is a result of "zone recording": the tracks in the "outside zone" of the hard disk have a lot more sectors (and thus data) than the inner tracks. As we only tested with a 20GB file on a total of 500GB (7x 73GB) of disks space, all disk activity was in the fast outside zone of the disks.

Latency is very low as we don't need to move the head of the hard disk; most of the time the heads stay on the outside tracks. When we have to move the heads, they only have to make a very small move from one track to an adjacent one. Random access is a lot more interesting...


With a 20GB file, the chance that the actuator has to move the head to jump to the next random block is a lot higher than with a 2GB file. In addition, the head movements become longer and are no longer only short strokes.

It now gets clear why the iSCSI SLES target performs so well at Random Reads. Look at the latency at 2GB; it's "impossibly low" as it is lower than the DAS configuration. This indicates that there is more cache activity going on than on the DAS configuration. Since both use the same RAID controller this "extra cache activity" is not happening on the level of the RAID controller but on the OS Level. Indeed, as we looked at the buffers of the SLES installation we saw the buffers increase quickly from a few KB to 1708MB. This means that the majority of our 2GB RAM on the Intel SSR212MC2 is caching the 2GB test file. Once we moved to 20GB this Linux file system caching could not help anymore and will probably add latency instead of lowering it. The Microsoft iSCSI target software does not seem to use this kind of caching.

This has an interesting result: the iSCSI SLES target is very interesting if you want the best random performance with a relatively small database. You can then try to put as much memory as possible in your iSCSI storage rack. On the other side of the coin is the fact that once the cache is too small, performance decreases quickly.

RAID 6 ?

As the Promise system was the only one with RAID 6 we did not put all our results in graphs. Our testing shows that RAID 6 is almost in every circumstance about 5 to 10% slower than RAID 5. For many people that will be a small price to pay as a failed disk no longer means that the array is unprotected until a replacement disk is installed. In case that the RAID 5 has to be rebuild, disks get accessed very intensively and as such disks are more prone to fail.

Management Interface

While it is not the focus of this article, we should mention that both the Intel Storage server and the Promise VTRAK E310f run a web server that offers management access to the storage server configuration via your LAN or the internet. Promise provides a very extensive GUI that guides users through all the possible options, a CLI and a menu driven CLU. The CLI or CLU can be accessed via a relatively fast 115200 serial connection. (We don't have fond memories of accessing the Cisco OS via a 9600 bps interface).


You use the CLI or CLU to setup password and the network IP, after which you can configure the disk array in a very nice GUI



Besides diagnostics, disk array management, and user management, it is also possible to set up several other services such as a mail server that warns you if one of the drives fails and if the hot spare has been used or not.



Intel's software is a bit more sober; you won't find red flashy lights going off on a picture of the rack if something is wrong. However, the Intel RAID web console does a great job of quickly showing all the technical data you need such as stripe size, caching policies, etc.