OCZ Rally2 in RAID0

In some tests, we've seen Linux' software raid capabilities outperform those of dedicated hardware solutions. Additionally, the only way we can create a raid configuration with two USB drives is through software. So, for our testing purposes, we're going to use the mdadm command to create a RAID0 between our two drives. In RAID0, data is split up and written between the two drives, allowing for faster read and write speeds.

Preparation

To avoid potential errors, we used fdisk to create a partition on each separate drive, which we than partitioned with the XFS filesystem to handle large files. After these stepsy were completed, we were ready to create our RAID device.

# mdadm --create /dev/md1 --level=0 --raid-devices=2 /dev/sda1 

  /dev/sdb1 --auto=yes

# mount /dev/md1 /mnt/usb

Looking a little closer at the mdadm command, we think the options we specified are fairly self explanatory. --create specifies what node in the /dev filesystem you want to create the array in; the md* series of names usually relate to raid devices. --level specifies what kind of RAID you want to create. We're not going to go into other types, just know that RAID0 usually gives the fastest results with the least amount of failure protection. --raid-devices specifies how many devices you're using (followed by the actual devices), and finally, auto auto-creates the node for you so everything is set up and re-creates if the drives are disconnected, which is quite useful for USB drives.

Benchmarking RAID0

Now that the drive is created and ready to be tested, we're going to run it through the usually benchmarks we used earlier.

# time dd if=/dev/zero of=/mnt/disk/test bs=1024 count=4000000

4.1 GB copied, 177.541 seconds, 23.1 MB/s

23.1MB/sec is a big improvement over the single drive performance, roughly 50%. Since data is being written on two drives at once, we're seeing faster drive speeds as a result. Next, we're going to user seeker to find the access time of the raid.

Results: 177 seeks/second, 5.64 ms random access time

This is an entire millisecond faster than the single drive, which may only seem like a small improvement, but when you consider your average 7200RPM hard drive's access time is in an excess of 12 ms or more, this seems like a bigger improvement. Unfortunately, I didn't have a chance to test the raid setup on my desktop, so I can't verify if they times are faster on my desktop. If you recall, my desktop showed a single drive having an access time of 3.79 ms, rather this machine's 6.x ms time.

hdparm also gives us a jump in performance:

RAID

Timing Cached Reads: 495.49MB/sec

Timing Buffered Reads: 37.44MB/sec

We're seeing mixed results here. The cached reads are down, but we thinks that's just from the overhead of running the raid. There's nothing horribly wrong with this speed, though. On the other hand, we're seeing approximately a 50% performance gain in buffered reads! That's the kind of performance jumps we want to see! We wanted to see if we could push this any farther, but hdparm doesn't give us many options for a USB device. The one option we found that gives us a boost in performance is the read ahead. This changes the amount of data that is read in advance. The default setting is 512kb, but we bumped it up to 1024 and 2048 to see if we saw any gain.

# hdparm -a1024 /dev/md0

Cached = Same

Buffered = 41.12MB/sec



# hdparm -a2048 /dev/md0

Cached = 35.65MB/sec

Buffered = 42.65MB/sec

As you can see, we've gained almost a 100% speed increase over a single drive. This is strictly for sequential readings, but if you can squeeze extra performance out, then why not? Especially if you're using large files on the drive, you're going to appreciate faster read-ahead times, and you will see the benefits of it. This setting won't, however, effect the write speeds.

As a last benchmark, we wanted to see what the worst-case scenario is for our drives. To do this, we mounted the raid device with the "sync" option. Doing this removes the RAM from the equation. Data is written between busses, and it isn't buffered through the RAM to increase overall speed. For example, have you ever pulled a USB drive from a Windows box without properly unmounting it? Chances are that you lost some files you recently saved to it. This is because that although the file transfer progress dialog closed, some data was still being written to the drive from RAM (sometimes, anyways), so you interrupted the file transfer and corrupted whatever data you'd just written to it.

Using the sync option means that the dialog won't close until the data is definitely on the drive.

mount -o sync /dev/md1 /mnt/usb

Let's us the dd command to write a gigabyte of data to the drive.

1.0 GB copied, 125.706 seconds, 8.1 MB/s 

That's a giant drop in performance. You're unlikely to come across this kind of performance unless you're utilizing all your RAM for other purposes.