danq@sag4.BERKELEY.EDU (Daniel Quinlan) (09/09/87)
I recently purchased _UNIX Papers for UNIX Developers and Power
Users_, a collection of articles on facets of UNIX edited by Mitchell
Waite, which had a number of interesting articles in it. On the whole,
it seemed to be worth the ~$25 I paid. However, the last article, by
Eric Raymond, contained the following assertion in a section titled
"Berkeley Redux: The Long, Slow Fall of BSD UNIX":
" .. The Fast File
System, a 4.2BSD enhancement intended to speed up system throughput,
has turned out to be considerably slower at supporting a typical multiuser
job mix than the code it replaced; it is now widely considered a technical
failure. .."
This was not my impression. Would anyone care to comment on this?
Daniel Quinlan
Space Sciences Laboratory, UC Berkeleyromain@pyrnj.uucp (Romain Kang) (09/12/87)
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!!''shor@sphinx.UUCP (09/12/87)
In article <670@pyrnj.uucp> romain@pyrnj.UUCP (Romain Kang) writes: >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. Actually, it probably is signficant that Cray has replaced the standard System V filesystem with a faster, bit-mapped filesystem. They found that the original just couldn't keep up. As for ETA, we won't know until they come out with a product, will we? -- Melinda Shore ..!hao!oddjob!sphinx!shor Pittsburgh Supercomputing Center shore@morgul.psc.edu
gwyn@brl-smoke.UUCP (09/13/87)
In article <2273@sphinx.uchicago.edu> shore@hawking.psc.edu (Melinda Shore) writes: >Actually, it probably is signficant that Cray has replaced the standard >System V filesystem with a faster, bit-mapped filesystem. With the adoption of the filesystem switch, this is relatively easy to do, and multiple filesystem implementations can be supported, which can be of great value when a system suddenly acquires a new filesystem format, especially if users have removable data packs.
allbery@ncoast.UUCP (09/18/87)
As quoted from <670@pyrnj.uucp> by romain@pyrnj.uucp (Romain Kang): +--------------- | 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 might be instructive for me to point out that Altos sells what they call the BoosterPak -- which is basically a version of Xenix 3 that has the Berkeley Fast File System. I haven't noticed much of a difference between an 886 with the BoosterPak and one without... ...except when the disk gets full... ;-) -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> All opinions in this message are random characters produced when my cat jumped (-: up onto the keyboard of my PC. :-)