For what it's worth, I'm *extremely* unhappy with the disk buffering 
strategy on NetBSD.  Last night, I was dumping my laptop's (1.6) disk 
to a drive on my desktop.  The desktop (-current, 1.6K) was completely
unusable during that time -- the disk was so busy that the machine 
seemed to be unable to page in Mozilla.  All the desktop was running 
for this backup was 'cat', which isn't that bloated (yet...).  It was 
writing to one file, so it's not a vnode cache issue.

I'm running with default vm.* sysctls, and softdep on.  Here's the 
drive info:

# atactl wd0 identify
Model: IBM-DTLA-307075, Rev: TXAOA50C, Serial #:          YSDYSFL9921
Device type: ATA, fixed
Cylinders: 16383, heads: 16, sec/track: 63, total sectors: 150136560
Device supports command queue depth of 15
Device capabilities:
        ATA standby timer values
        IORDY operation
        IORDY disabling
Device supports following standards:
ATA-2 ATA-3 ATA-4 
Command set support:
        NOP command
        READ BUFFER command
        WRITE BUFFER command
        Host Protected Area feature set
        release interrupt
        look-ahead
        write cache
        Power Management feature set
        Security Mode feature set
        SMART feature set
        Advanced Power Management feature set
        READ/WRITE DMA QUEUED commands
Command sets/features enabled:
        look-ahead
        write cache

The CPU is a ~750 Mhz Athlon with a VIA chipset and 256M of RAM.  And 
I'm extremely unhappy with interactive performance these days.  (It was 
embarrassing, too -- I was trying to order something on the Web for my 
son last night, and I had to suspend the backup process to do so.  He's 
always hearing from me how much better Unix is than Windows at 
timesharing...)

Now -- going back 25 years, Unix has never been at its best in the face 
of a heavy I/O load, because of the lack of a priority feedback scheme 
in the disk scheduler.  A process that uses too much CPU is penalized 
relative to other processes; the same is not true of I/O.  Even if it 
were, that wouldn't necessarily help, because stuff is being thrown out 
of the buffer cache far too rapidly, causing a lot of unnecessary I/O 
bring things back in.



		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)