MSCP SCSI controller speed
brad at heeltoe.com
Wed Nov 9 13:17:42 CST 2005
Paul Koning wrote:
>All you need is an application, or OS, that can queue up multiple
>transfers. I thought the buffered I/O in Unix would take care of
er, ah. I think that's why they created "async i/o" in unix (I first
saw it in solaris). I don't think bsd will read-ahead in a file, but I
may be wrong.
Writes will certainly buffer up and overlap but I don't think reads
will. Each read will block until it completes (ignoring the buffer
cache). After it completes nothing will happen until another read
occurs. I think this is modulo the basic i/o size (page size in bsd?)
but still true.
"dd if=syssrc.tar of=/dev/null"
will read, slowly. I would be interesting to see how long (in comparison)
these two took:
dd if=syssrc.tar of=/dev/null bs=16k count=1000
dd if=/dev/zero of=blah.null bs=16k count=1000
I suspect the write will be faster, and reflect the true speed of the i/o.
if I'm all wet please correct me. things have changed in the flow from
2.9,2.11,*bsd->sunos->solaris->freebsd->netbsd->linux :-) Modern *nix's
are more proactive and blur the line between vm pages and file buffer
blocks (which is good).
(can you mmap a file in bsd? if you can then you could simulate read-ahead
by just peeking at a byte 16k ahead of where you are copying from. but
I don't think you can mmap files in bsd. too bad. everything should be
in your local address space :-)
More information about the cctech