Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ladcgw!hermes!fmayhar
From: fmayhar@hermes.ladc.bull.com (Frank Mayhar)
Newsgroups: comp.unix.wizards
Subject: Re: Raw disk I/O
Message-ID: <1990Feb25.202513.25515@ladc.bull.com>
Date: 25 Feb 90 20:25:13 GMT
References: <1990Feb23.223030.9851@ladc.bull.com> <132220@sun.Eng.Sun.COM>
Sender: news@ladc.bull.com (Usenet News)
Organization: Bull HN Information Systems Inc. Los Angeles Development Center
Lines: 36

In article <132220@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
>In article <1990Feb23.223030.9851@ladc.bull.com> fmayhar@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@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