Curt Sampson writes:
> What controller are you using?

Adaptec 2940UW.

> Can you try out a different controller?

That's all we have (and we have 4 of them), unless you want to count an
ancient Adaptec 1522.

Michael L. VanLoon writes:
> 
> I have a few suggestions for you.
> 
> 1) It doesn't look like you're using tagged command queuing.  That
> will improve performance more than anything you can do.  Rebuild a
> kernel with "options AHC_TAGENABLE" in it, and boot that.

Is there any danger involved in this? If not, then why is this option
not enabled by default? (I don't really want to destroy the data on my
disk!)

> 2) Try running these benchmarks while running a program at the same
> time that eats 100% of available CPU.  It should accumulate more run
> time while the SCSI drive is busy.

You mean compared to the IDE? That is pretty much a given. I'm not
interested in trying to show that an IDE disk is better than a SCSI,
just wondering why my SCSI file system performance sucks so bad.

> 3) Try running these tests on a ccd striped over two or more identical
> drives.

   Disk /dev/rccd0a bandwidth         12138 KB/sec
   File /n/picu/1/XXX write bandwidth: 2328 KB/sec

We've had two machines running with striped Seagate 15150W's (same disk
as the other machine) for about 6 months now with 0 reliability
problems. I'm hoping I can get better performance though.

> 4) Try 2 & 3 while multiple instances of a disk benchmark are running
> on the same and/or different drives (of the same type) simultaneously.

The idea here is to see if it's a per process or per disk/controller
limitation, right? I'll try this if the AHC_TAGENABLE thing doesn't give
a good performance increase.