Blocking for disk I/O (was Re: Must UNIX be a memory hog?)

[Kenneth Almquist]

> On this system, as on several others, I've replaced /bin/true and /bin/false
> with executables (which will be left as an exercise for the reader, since
> posting them would be an intellectual insult to any True Unix Wizards ;-).
> I've verified that the result is a measurable speedup in "while true"
> loops, due to the elimination of the shell startup to run an empty script.

I didn't believe this, so I tried executing the following loop:

	x=200
	while ./true
	do	x=`expr "$x" - 1` || break
	done

When ./true was the empty file, the execution time was

	8.2 real    0.4 user    3.4 sys

Using a compiled C version of ./true decreased the real time to

	6.4 real    0.5 user    4.2 sys

These numbers are from ash; using /bin/sh instead produced a similar
relative results:

	28.0 real   2.0 user    15.4 sys
	25.6 real   1.8 user    15.8 sys

The system time makes sense:  When ./true is a shell procedure rather
than an executable, there is no need to load a new program into memory.
(A new process is needed in either case, but if ./true is a shell
procedure, only a fork is needed, not a fork and an exec.)  But what
about the real times?  Why aren't they the same as the user plus the
system times?  One clue is that when ./true is a shell procedure, the
name ./true is looked up twice.  This is because an exec of ./true is
done, and only when that fails does the shell realize that ./true is
a shell procedure and open it.  So I tried writing a little C program
that opened and closed a file in the current directory 1000 times:

	17.3 real    0.0 user    3.2 sys

This is on an otherwise idle system running Ultrix 3.0, a 4.2 BSD
derivative.  I assume that it is blocking on disk I/O, but the machine
has an 800K buffer cache, which ought to be large enough to hold every
block that the open system call accesses.  I know that on AT&T versions
of UNIX, certain system calls use synchronous I/O to ensure that the
file system is left in a relatively consistent state in the case of a
system crash.  But open?  Is this a fanatical attempt to be sure that
file access times aren't lost in a system crash, or what?  Anyone
figured this out?
				Kenneth Almquist