Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!pyrnj!romain
From: romain@pyrnj.uucp (Romain Kang)
Newsgroups: comp.unix.questions
Subject: Re: BSD Fast File System a Flop?
Message-ID: <670@pyrnj.uucp>
Date: Fri, 11-Sep-87 23:21:23 EDT
Article-I.D.: pyrnj.670
Posted: Fri Sep 11 23:21:23 1987
Date-Received: Sat, 12-Sep-87 22:56:10 EDT
References: <5027@jade.BERKELEY.EDU>
Reply-To: romain@pyrnj.UUCP (Romain Kang)
Organization: Pyramid Technology Corp, Woodbridge, NJ
Lines: 42

Since no one else has followed up yet, I guess I'll bite.  Without
having read that article, I would wonder whether there's confusion
between filesystem performance and total system performance, since
the initial 4.2 release was relatively untuned.  Still, the Fast File
System could be a liability rather than an asset to some systems.

The Fast File System is more CPU intensive than the V7 filesystem.
Kirk McKusick has commented that the Fast File System is
"over-engineered for VAX 11/750 systems", while such systems probably
formed the bulk of 4.2 BSD installations when it was first released.
The impression that I got was that FFS, like GNU project software, was
designed for hardware just slightly ahead of its time; McKusick
seemed to suggest that a lot of CPU cycles were spent figuring
out how to get data to user processes that couldn't keep up the
incoming I/O.

By way of comparison, I seem to recall Peter J. Weinberger's V8
filesystem was a less radical departure from the V7 design, but still
plenty fast.  I believe Weinberger dubbed it the "sufficiently fast
file system" since user processes still couldn't keep up with the disk
I/O.  Perhaps he believed he would be stuck with 750's for a long time.

It might be an interesting experiment to try running today's Sun
workstations with a System V filesystem instead of FFS under the vnode
layer.  These and many other new Unix boxes are typically several times
faster than the old-style VAX CPUs, but may have fairly slow disks and
perhaps dumber disk controllers.  In this case, disk layout becomes
more important -- if you were a fast CPU, waiting for the disk might be
like waiting for the second hand on a wall clock to reach the next
quarter-minute mark.  You might get around this with a large buffer
cache.  In fact, I believe some System V implementations recommend
allocating as much as 50% of main memory to cache.

It is probably not significant that supercomputer implementations of
Unix (Cray, ETA) appear to use the System V filesystem, since they
would typically run CPU-bound rather than I/O-bound jobs, on top of
having superior I/O subsystems and oceans of memory.
--
Romain Kang		{allegra,cmcl2,mirror,pyramid,rutgers}!pyrnj!romain

''!!!x0289 dimaryP a fo edisni deppart m'I  !pleH``
``oNhwre eenraa  sab dsab iegnt arppdei  n aAV X117/05!!''