Here are some additional tests that have occured to me, in no particular order:

• Swap hdc and hdg for instance to see if the poorer performance of eastwood's hdc follows the drive, or sticks with the controller.

• Try adding an additional PCI-X IDE controller.  Then the two current slaves could become masters and possibly all be accessible simultaeously, allowing 4 disks in RAID0 or RAID5 while avoiding the Intel controller, which may be inferior.

• Try the "-e" option with IOzone to try to force disk access and reduce memory caching.  A good test set is hdh and raid0.  (These are done -- results to be posted)

• Try IOzone with 1/2 or even 1/4 of the RAM (1GB or 512MB).  (tests with 1 GB RAM are done -- results to be posted)

• Vary the RAID0 stripe size?

• Vary the ext2/ext3 block size.

• Try different ext3 journalling modes (journal (the default), ordered and writeback).

• Filesystems other than ext2/3 (Reiser, JFS, XFS, ?).  Support from Redhat for any filesystem other than ext2/3 is essentially non-existent, so any foray down this path will take some extra effort.

• Try running through database benchmarking with multiple clients ("super parallel" access), in the manner of Mike DePhillips's testing of STAR offline database servers.

• Multi-threaded/multi-process testing, possibly with IOzone.

• IOzone has tests for mmap and POSIX async I/O.  I don't know if either of these is relevant to any STAR uses.

• Try different I/O elevators (see for instance http://www.redhat.com/magazine/008jun05/features/schedulers/ )

• IOperf - stalled on timing issues.