Re: I/O or Threading Suffer

On Wed, Jul 21, 2004 at 07:07:00PM +0200, jesk wrote:
> > Ah. now that's a different story.  You're out of the control of the
> > process scheduler and into the disk.  I don't suppose you're using an
> > IDE/ATA disk with no tagged queueing? :) Run "dmesg | grep depth.queue"
> > to see how many requests can be queued up on your disk at once.
> >
> > That dd is stuffing lots of dirty data into the disk cache, and all the
> > other processes have to wait in line to get their I/Os done.  You'll
> > see much better results from a SCSI disk (with usual queue depths
> > between 32 and 64), and even better results from a multi-disk hardware
> > RAID array (which will have a large write cache).
> >
> > --
> > Dan Nelson
> > dnelson_at_allantgroup.com
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> >
> >
> when system doesnt response any more in cause of high write operations
> on the disk then the reason for this is not looked up in the device device
> configuration or in non-scsi hardware ;)

I have to agree with Dan here. I tried the simple dd test on one of my
5-current systems here that has both IDE disks and an LSI 320-2 SCSI
RAID controller with 256 MB of writeback cache. When running the dd to
one of the IDE drives the delay was _very_ noticable when attempting
simultaneous commands that did I/O to that same disk (often the command
didn't seem to even run till the dd completed). However, when doing this
same thing to a filesystem on the LSI array their was no decernable
delay (though the command did take abit longer to run).

So, in my case anyway, I was seeing what I'm convinced was I/O
starvation on the IDE disk but not on the hardware RAID controller
attached disk.

Bob

-- 
Bob Willcox                   Serocki's Stricture:
bob_at_immure.com                  Marriage is always a bachelor's last option.
Austin, TX