A warning about read(2)/write(2)

[Richard A. O'Keefe]

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.)