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