Raw disk I/O

Frank Mayhar fmayhar at hermes.ladc.bull.com
Mon Feb 26 07:25:13 AEST 1990


In article <132220 at sun.Eng.Sun.COM> lm at sun.UUCP (Larry McVoy) writes:
>In article <1990Feb23.223030.9851 at ladc.bull.com> fmayhar at hermes.ladc.bull.com writes:
>>... blocking I/O.  We got about
>>40k-45k/s.  With block-mode I/O, we get from around 90 k/s to as much as
>>200 k/s or a little more, depending on the test parameters.  Are you saying
>>that we could exceed these figures using raw I/O?
>I sure hope so.  Those are pathetic I/O rates.  
> [shows example giving 420k/s rate on Sparcstation 1]
>It's probable that you are doing radom I/O so I wrote a little program
>that uses rand(3) to calulate the offset into the drive (see below) and
>that gives me about 180 Kb / sec (you can really hear the old head seeking).
>This assumes that I need all of the 8k block that I read. If you have smaller
>records, you'll get worse throughput.  For example, if you only need one byte
>of that 8k, your throughput goes down by a factor of 8192.  

Well, I'm doing I/O in 1k chunks, not 8k, so that should make some difference.
(Hmmm.  I wonder what would happen if I did some kind of read-ahead?  I.e.
read in 8k chunks, and buffer them until the caller needs them, flushing
the buffer when he does a seek into another part of the disk.  Hmmm.  Maybe
multiple buffers?)  Also, the system is a Bull XPS-100 running SVR2, so that
will make a little more difference (not much, though).  I'm doing both random
and sequential I/O (in different tests).  Actually, the random I/O gets a
tiny bit better throughput, since there's a caching scheme between the
user and the disk.

The real problem, I guess, is that I have to do this for multiple users,
concurrently.  It's hard to have a separate I/O process for *each* of
a large number of users.  I could make an entirely separate I/O server,
which does nonblocking I/O using a separate process, but I _still_ fail
to see how that's different than just going through the block device driver.
It also has the disadvantage that there's a communication bottleneck in
this scheme, that's taken care of by the OS when using the device driver.
--
Frank Mayhar  fmayhar at hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241



More information about the Comp.unix.wizards mailing list