Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!hammond
From: hammond@faline.UUCP
Newsgroups: comp.arch,comp.os.misc
Subject: Re: Unix File System Performance
Message-ID: <1384@faline.bellcore.com>
Date: Sat, 12-Sep-87 14:02:42 EDT
Article-I.D.: faline.1384
Posted: Sat Sep 12 14:02:42 1987
Date-Received: Sun, 13-Sep-87 09:02:39 EDT
Reply-To: hammond@faline.UUCP (Rich A. Hammond)
Distribution: world
Organization: Bellcore MRE
Lines: 31
Xref: utgpu comp.arch:2039 comp.os.misc:160

In article <> martin@felix.UUCP (Martin McKendry) writes:
>
> ...  A 
>very high proportion of programs today are I/O bound -- a proportion 
>that will increase as we get faster processors.  It seems to me that 
>filesystem performance is the next big area for competition.  After 
>all, that's what makes a mainframe a mainframe, right?
>
>Comments?

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?

On machines with 32+ MB of memory, I'm willing to bet that a large
proportion of all accesses are satisifed from the in core buffers,
i.e. my edit compile run edit cycles probably all run out of the in
core buffers once I've completed a cycle.  If the system were smart
enough to use all of memory as disk buffer rather than 10% of it, I'm
certain that my stuff would just stay in core.

I'll agree that file system performance could be improved, but I'm
inclined to believe that improving the use of main memory as buffers
would be a bigger general win than any changes to the disk layout.

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.

Rich Hammond	Bell Communications Research	hammond@bellcore.com