Advice configuring ServeRAID 8k for performance - Mailing list pgsql-performance

I am using PostgreSQL 8.3.7 on a dedicated IBM 3660 with 24GB RAM running
CentOS 5.4 x86_64.  I have a ServeRAID 8k controller with 6 SATA 7500RPM
disks in RAID 6, and for the OLAP workload it feels* slow.  I have 6 more
disks to add, and the RAID has to be rebuilt in any case, but first I
would like to solicit general advice.  I know that's little data to go on,
and I believe in the scientific method, but in this case I don't have the
time to make many iterations.

My questions are simple, but in my reading I have not been able to find
definitive answers:

1) Should I switch to RAID 10 for performance?  I see things like "RAID 5
is bad for a DB" and "RAID 5 is slow with <= 6 drives" but I see little on
RAID 6.  RAID 6 was the original choice for more usable space with good
redundancy.  My current performance is 85MB/s write, 151 MB/s reads (using
dd of 2xRAM per
http://www.westnet.com/~gsmith/content/postgresql/pg-disktesting.htm).

2) Should I configure the ext3 file system with noatime and/or
data=writeback or data=ordered?  My controller has a battery, the logical
drive has write cache enabled (write-back), and the physical devices have
write cache disabled (write-through).

3) Do I just need to spend more time configuring postgresql?  My
non-default settings were largely generated by pgtune-0.9.3:

     max_locks_per_transaction = 128 # manual; avoiding "out of shared
memory"
     default_statistics_target = 100
     maintenance_work_mem = 1GB
     constraint_exclusion = on
     checkpoint_completion_target = 0.9
     effective_cache_size = 16GB
     work_mem = 352MB
     wal_buffers = 32MB
     checkpoint_segments = 64
     shared_buffers = 2316MB
     max_connections = 32

I am happy to take informed opinion.  If you don't have the time to
properly cite all your sources but have suggestions, please send them.

Thanks in advance,
Ken

* I know "feels slow" is not scientific.  What I mean is that any single
query on a fact table, or any 'rm -rf' of a big directory sends disk
utilization to 100% (measured with iostat -x 3).