Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!elroy.jpl.nasa.gov!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.sysv386
Subject: File system performance
Summary: somewhat complicated...
Message-ID: <1990Oct31.212543.28245@ico.isc.com>
Date: 31 Oct 90 21:25:43 GMT
References: <267@srchtec.UUCP> <1990Oct19.130404.25352@nstar.uucp> <1990Oct31.120401.4814@nstar.uucp>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 42

larry@nstar.uucp (Larry Snyder) writes:

> I am wondering just how fast the FFS is as compared against other fast
> file systems --

Not too surprisingly, we've looked at that a bit.  One answer stands out
like a sore thumb:  If you're running V.4, *don't* use the old-style s5
file system unless you really need it.  The BSD-style file system is a far
better performer.

Terminology:  The main two file system types in V.4 are called "s5" and
"ufs"--these are the old-style System V (V 7 style, if you will:-), and the
BSD-style, respectively.  (There are others like the boot file system,
proc, etc.  They're special-purpose.)

Looking at performance of V.4 ufs vs s5, ufs wins hands-down.  For example,
Tim Bray's "bonnie" takes about 50% longer, overall, on s5.  There's a lot
more CPU time burned in s5.  It's fair to say that the V.4 s5 file system
has the same performance as a stock V.3 file system.

Comparing V.4 ufs to ISC's FFS (our V.3.2 "fast file system") is a much
more interesting exercise.  They're really pretty close.  This isn't
surprising, since they both get their major performance gains from two
factors:  intelligent allocation and dealing in larger chunks.  The
interesting part is that FFS performs better on a smaller machine; ufs
pulls ahead of it a bit on a machine with lots of memory.  The reason, it
turns out, is not really related to the file system implementation.
Rather, V.3 has a statically-allocated buffer cache, while V.4 allocates
memory dynamically.  On a V.4 system, if the memory load due to program
space is low, the buffer cache will grab more memory...so if you've got
oodles of memory to start with, you can get a pretty substantial cache
going.  On V.3, you can allocate a huge cache, of course, but it stays
allocated; if the machine load shifts away from I/O and toward large
processes, you're wasting memory.  I suspect (but haven't really con-
firmed) that the reason the V.3.2 FFS does better on non-huge machines is
just that the code is cleaner and spends a little less time fiddling with
special cases that turn out not to matter.  I suspect that cylinder groups
(present in ufs but not FFS) don't help much; they may actually be the
hindrance that makes the performance difference.
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...but Meatball doesn't work that way!