486 computers and Unix

[Piercarlo Grandi]

In article <713 at nox.se> peter at nox.se (Peter Levin) writes:

  The machine had 4 Mbytes of memory (the recomended size by SCO for a small
  machine with limited number of users).  The big problem was the SCSI tape
  drive (Archive 150 Mbyte internal).  The tape drive worked perfectly in
  single user mode.  In multiuser mode it hanged after a couple of tape
  actions.  Sometimes it started up again after one minute or an hour.  SCO
  had no solution.  After adding 4 Mbytes extra, the drive was working
  without error.

The reason is obvious -- you were using the special device files that imply
tape buffering to access the tape. When you do this, the driver allocates a
number of pages of memory to buffer IO to/from the tape, so as to give the
illusion of asynchronous operation, and make the tape stream. If there are
not enough (contiguous, usually) pages to sustain the buffering, which is
easily the case on a loaded machine, problems happen -- the tape driver waits
for these pages, and looks locked up.

The solution is better integration between the tape driver and the memory
management so that the tape driver does not need luck to find the free
pages; the kludge is to add so much memory that lots of it lie unused, so
that the tape driver can always be lucky. The answer is the same to the
problem of how to avoid expansion swaps, one of the most demented and
ridiculous mistakes done by AT&T: avoid exercising the troublesome code by
making sure a lot of memory is wasted.

This problem occurs, as far as I know, with nearly every buffering tape
driver around. Buffering should not be done in the driver at all -- it
should be done by a user utility. If the kernel were well implemented, this
would not just work better, it would also have small overheads.
-- 
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk