A warning about read(2)/write(2)
Richard A. O'Keefe
ok at quintus.uucp
Mon Jun 20 17:57:35 AEST 1988
In article <425 at sp7040.UUCP> sbc at sp7040.UUCP (Stephen Carroll) writes:
>In article <122 at quintus.UUCP>, ok at quintus writes:
>> The package I am talking about was reading and writing 56 byte chunks,
>> so it was doing a system call and a disc access for every 56 bytes.
>> (And since 56 does not divide 8192 evenly, some of these transfers
>> could cost two disc accesses.)
>
>WRONG!!!! You could read and write 1 byte at a time, but this does not create
>a disk access for each system call. It is true that read/write causes a
>system call on each invocation, as compared to stdio, but Unix DOES NOT read
>and write the disk on each of those system calls.
Oh drat, insufficient context. I was confusing two things in my comments.
(1) the program in question was doing read(2) and write(2) instead of
stdio calls, so it was getting a lot more system calls than it needed
(2) it was ALSO doing a lot of seeks (which I didn't mention) so each of
those reads and writes tended to turn into an actual disc access
because they weren't adjacent. FOR THIS PARTICULAR PROGRAM, it is the
case that UNIX *does* end up doing one disc access per read(2) or
write(2). [You can use the BSD "time" command to find out how many
accesses are happening.] Any program which does nearly as many seeks
as transfers is likely to see the same thing.
There are two points which I was trying to make:
(1) if you are doing sequential I/O, using read(2) and write(2) is _not_
a win over stdio, because you do more system calls.
(2) if you are doing random I/O into a disc file, the way to better
performance is to try to do a few large transfers, with as much
useful work per transfer as possible. At this level of hacking,
read(2) and write(2) may be appropriate, but they aren't _enough_.
Caution to wizards: don't jump to the conclusion that someone misunderstands
UNIX. He may be quoting quite accurately what time(1) says that particular
program is doing. (He may also be bad at explaining things.)
More information about the Comp.unix.questions
mailing list