Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!preece
From: preece@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: Unix File System Performance
Message-ID: <28200045@ccvaxa>
Date: Sun, 13-Sep-87 12:54:00 EDT
Article-I.D.: ccvaxa.28200045
Posted: Sun Sep 13 12:54:00 1987
Date-Received: Fri, 18-Sep-87 07:12:25 EDT
References: <7075@felix.UUCP>
Lines: 44
Nf-ID: #R:felix.UUCP:7075:ccvaxa:28200045:000:2141
Nf-From: ccvaxa.UUCP!preece    Sep 13 11:54:00 1987


  hammond@faline.bellcore.com:
> About 98% of the programs run on our systems use <2 secs of 780 CPU
> time, nor do they use very much I/O.  There are only a few I/O or CPU
> hogs.  That's based on ~10 million process records using modified 4.2
> BSD accounting.  Where do you get the idea that a high proportion are
> I/O bound?

> Does anybody have records for their general use systems that prove that
> the systems are I/O bound?  I want at least a continuous month's worth
> of records, no one or two day or "peak" samples.
----------
So what's "general use" and who cares about it anyway?  Every machine
has its own workload profile; a filesystem optimized for one is very
likely to be inadequate, or at least sub-optimal, for many others.
While the "traditional Unix" load may indeed tend towards short
execution times and light filesystem activity, but a great many Unix
machines today are sold to entirely different kinds of users.

A user with a large office automation system, heavily dependent on an
underlying database, is probably going to want a wildly different
filesystem implementation (probably different enough that it will have
to be custom built and avoid Unix I/O entirely because the Unix I/O
strategy is inadequate for its needs).  A real time system which needs
to generate a megabyte per second of status and checkpoint information
is not going to want to run it through the buffer cache.

There are a lot of users who want to KNOW when their i/o has actually
finished (not just been accepted by the system), so they know when the
filesystem is safe.  There are users who know that they need to generate
lots and lots of tiny files and there are users who know that they need
to generate one or two huge files.

The buffer cache and the BSD fast filesystem are very nice for some
kinds of workloads (including the general software development load that
probably characterizes the bulk of the readers of this notesfile), but
to believe that it is all that is necessary is to grossly restrict the
market for your systems.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@Gould.com