>On one system that has:
>   wd0 at wdc0 drive 0: 2014MB, 4092 cyl, 16 head, 63 sec, 512 bytes/sec
>   <QUANTUM FIREBALL_TM2100A>
>   wd0: using 16-sector 16-bit pio transfers, lba addressing
>I get the following figures (extracted from the raw data file created by
>lmbench):
>   Disk /dev/rwd0a bandwidth          4474 KB/sec
>   File /usr/tmp/XXX write bandwidth: 3595 KB/sec

>On the other hand, on a machine with:
>   ahc0: target 0 using 16Bit transfers
>   ahc0: target 0 synchronous at 10.0MHz, offset = 0x8
>   sd0 at scsibus0 targ 0 lun 0: <SEAGATE, ST15150W, 0023> SCSI2 0/direct fixed
>   sd0: 4095MB, 3712 cyl, 21 head, 107 sec, 512 bytes/sec
>I get:
>   Disk /dev/rsd0a bandwidth          6677 KB/sec
>   File /usr/tmp/XXX write bandwidth: 1466 KB/sec

>So how is it that raw read performance is so much better on the SCSI
>drive, but file system write performance is so much better on the IDE?
>Does this have something to do with what lmbench is doing, or is it
>something in interaction between FFS and the drivers? Clues?

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.

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.

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

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.

-----------------------------------------------------------------------------
  Michael L. VanLoon                           michaelv@MindBender.serv.net
        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...
-----------------------------------------------------------------------------