Monday, February 20, 2006

OS X RAID Benchmarks

I picked up two 500 GB Lacie Big Disk Extreme external hard drives. The Big Disk Extreme supports USB 2.0 and Firewire 400 and 800. The drives came with all the necessary cables (including an iLink cable in case I want to daisy chain my video camera). I originally planned to mirror the drives using OS X's built-in RAID support so I wouldn't have to worry about backups anymore, but after benchmarking various configurations using Xbench, I think I'll synchronize the drives nightly using Carbon Copy Cloner (CCC) or rsync instead. I tested five different configurations:
  1. The internal 250 GB drive that came in my Quad G5
  2. A single drive connected via Firewire 400
  3. A single drive connected via Firewire 800
  4. Two drives mirrored, one drive connected via Firewire 400, the other via Firewire 800
  5. Two drives mirrored and daisy chained using Firewire 800
All tests were uncached per Xbench. The internal hard drive benchmarks may be artificially slow: the external hard drive has no data on it while the internal drive holds the operating system and all my applications and data. I quit most of the applications, but some processes most likely accessed the internal drive during the test. Is Firewire 800 worth it? Firewire 400 theoretically supports 50 MB/s transfer rates while Firewire 800 supports up to 100 MB/s. The drives far exceeded 50 MB/s in a few tests indicating that using Firewire 800 really does make a difference (sorry MacBook owners). I'm actually surprised by how much better the Firewire 800 configuration performed; perhaps you can attribute the difference to round trips or some other communication overhead. Given that all my computers support Firewire 800, I'm glad I sprung for drives that support it as well. The sluggishness of random 4k block reads across all the configurations shocked me; every test came in at much less than 1 MB/s. I knew it would be slow but not that slow. I'll keep that in mind the next time it comes up in an application design. The mirrored, daisy chained Firewire 800 configuration performance also disappointed. I correctly expected the writes to take twice as long as those for a single Firewire 800 drive, but I incorrectly expected the reads to perform as much as two times faster. Instead the reads were much slower in both sequential cases, the same in the 4k block random read, and only slightly faster in the 256k block random read. In the hopes that putting the drives on separate buses would improve performance, I tried connecting one drive to the Firewire 400 port, but the performance was much worse. To top it off, OS X thought the drives were out of sync and proceeded to catch them up. Based on how long the resync was taking before I canceled it, I suspect OS X was comparing the drives bit by bit, all 500 GB. I ended up erasing and repartitioning so I could run the test. Based on my findings, I'm going to forgo RAID, partition the drives separately, and synchronize them nightly using CCC or rsync. Handling synchronization at the application level will result in more transparency (no worrying about long Disk Utility resyncs and less worrying about how to recover in the event of a failure). I'll get much better write performance and slightly better read performance in real world situations (video editing, etc.). On the downside, I'll have two drives on my desktop instead of one, and I'll risk losing a day's worth of data (or however long I go between syncs). Then again on the upside, I should only mount the backup during syncs which means virii, etc., won't be able to touch it. Now to spoof a .Mac account backed by these puppies.

2 Comments:

Blogger Bob said...

That's awesome. I'm starting to wish I went with an SATA solution myself. Oh well; it's still faster than my internal drive, and I can plug one up to my laptop should I need to. ;)

8:06 AM  
Blogger Bob said...

I'm starting to think I may not have gotten double read speeds for the dual 800 configuration because I reached a limitation of Firewire 800. The 256k sequential read which should be the fastest out of the tests only got about 70 MB/s. Real world performance vs. 100 MB/s theoretical, read overhead, i.e. data other than the data you're reading, and especially round tripping, 256k is still pretty small, could all account for the missing 30 MB/s.

8:16 AM  

Post a Comment

<< Home