File system performance
Dick Dunn
rcd at ico.isc.com
Thu Nov 1 08:25:43 AEST 1990
larry at 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 at ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870
...but Meatball doesn't work that way!
More information about the Comp.unix.sysv386
mailing list