Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcrdcf.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!sdcrdcf!jonab
From: jo...@sdcrdcf.UUCP (Jonathan Biggar)
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <1679@sdcrdcf.UUCP>
Date: Thu, 17-Jan-85 13:28:19 EST
Article-I.D.: sdcrdcf.1679
Posted: Thu Jan 17 13:28:19 1985
Date-Received: Tue, 22-Jan-85 04:36:32 EST
References: <182@wdl1.UUCP>
Reply-To: jo...@sdcrdcf.UUCP (Jonathan Biggar)
Organization: System Development Corp. R+D, Santa Monica
Lines: 79
Summary:
In article <1...@wdl1.UUCP> j...@wdl1.UUCP writes:
4.2BSD is an experiment that seems to have failed. I am speaking
only of the kernel, not the rest of the system here.
I think you are reading too much into the intentions of the designers of
4.2bsd. They never planned that 4.2 should be the "be-all and end-all" of
operating systems. If you want that, try VMS. :-) 4.2 is an experiment on
a very large scale. The features that have been added are things that users
have desired for many years. The experiment is to find out how useful these
features are.
The much-touted ``fast file system'' does not seem to deliver
anything like the promised order of magnitude performance
improvement; in fact, overall 4.1BSD seems to slightly outperform
4.2.
The "fast file system" really does give you up to an order of magnitude
improvement. I have seen the entire 4.2bsd kernel compile in about half the
time it took to compile the 4.2 kernel in single user mode. This
improvement comes entirely from the file system because the 4.2 kernel is
not smaller, and the C compiler is not faster. The speed is there, but
supporting other features slowed 4.2 down. There Ain't No Such Thing As A
Free Lunch. Thinks of what 4.2 would be like with a v7 file system.
(Shudder!)
4.2BSD has a huge resident kernel because of the large number of new
and in many cases little used features. There are far more bugs,
security holes, and general problems than with 4.1.
Again, you miss the point. Whenever you add new features, it takes time to
determine all of the reliability and security rammifications. 4.2 was late
anyway, would you have wanted Berkeley to wait 2-3 more years until they got
out "the last bug"? Comparing 4.2 with 4.1 is fallacious. 4.1bsd is the
result of quite a bit of fine tuning over time. The features of the system
did not change much from 3.0bsd to 4.1bsd except job control. Thus 4.1 is a
good balanced, well tuned system that did its job well. 4.2bsd added new
features that no other unix system had. It is going to take a while to tune
4.2 to deliver maximum performance. Some of this work has already been done
and hopefully will be released soon.
The most significant addition was the support for networking, which
may be the last gasp of the networking-inside- the-operating-system
approach. (The state of the art is to use intelligent networking
cards; Excelan and Communications Machinery make cards that provide
IP/TCP services on an Ethernet; these cost about the same as ordinary
dumb Ethernet cards.)
I differ with you here also. Intelligent networking cards in no way make
kernel networking support obsolete. I think if you look, you will find that
kernel packages to support these cards under 4.2bsd are available. This
actually shows how well Berkeley designed the network software. You can
offload the TCP processing to an auxillary processor without changing the
interface that a program sees at all.
Other than networking, it is hard to point to a new feature in the
kernel that is really necessary and is in fact used by any
significant volume of software.
Nothing is "really necessary". Do you want us all to go back to v6. (After
all, who needs files larger than a megabyte or two anyway?) Not much of the
software uses the new features because the software was written before the
new features were available. Eventually this may change but very little
user application code has actually changed since v6. Your definintion of
necessary only includes features that you think YOU might need.
What are other's thoughts? Was all the trouble worth it? Should
further work proceed from a 4.1 base? A system V base? Or what?
Well, you got my thoughts. I thing 4.2 is a good place to continue the work
from. After usng 4.2 for six months, I never want to go back to 4.1. There
are just too many features of 4.2 that I don't want to do without.
Considering that 4.2 is capable of emulating almost all of system V's
features, it is much easier to port programs from system V to 4.2 than vice
versa. Doesn't that seem to say that 4.2 provides a better general base for
the future development of UNIX?
Jon Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3}!sdcrdcf!jonab
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hao!cires!nbires!opus!
rcd
From: r...@opus.UUCP (Dick Dunn)
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <1036@opus.UUCP>
Date: Fri, 18-Jan-85 03:23:58 EST
Article-I.D.: opus.1036
Posted: Fri Jan 18 03:23:58 1985
Date-Received: Wed, 23-Jan-85 08:53:45 EST
References: <182@wdl1.UUCP>
Organization: NBI,Inc, Boulder CO
Lines: 53
> 4.2BSD is an experiment that seems to have failed.
Careful here. An experiment which fails is one which produces no results
or conclusions. I think that 4.2 has given us a wealth of information.
Arguably it may have produced more information than code with long-term
usefulness, but that's too early to tell.
>...I am speaking only of
> the kernel, not the rest of the system here. The much-touted ``fast file
> system'' does not seem to deliver anything like the promised order of magnitude
> performance improvement; in fact, overall 4.1BSD seems to slightly outperform
> 4.2.
The kernel work was the most ambitious, yet it seems to be the best of the
work. There were mistakes in the kernel. My suspicion is that the fast
file system actually has some significant improvements which are masked by
some screwups and some changes elsewhere. There hasn't been a lot of
real-world experience reported (outside of Berkeley, for the sake of non-
biased views and replication) to judge by. Still, the kernel work is an
both genuinely useful and an order of magnitude better than what went on in
other areas--some of it best described as blind hacking that we'll be
finding and fixing for the next couple of years at least.
>...4.2BSD has a huge resident kernel because of the large number of new and
> in many cases little used features...
Software development goes in cycles. You try out a bunch of new ideas and
cobble something together to see if the ideas will really work. Things get
screwed up here and there; the code gets hacked over and balloons on you.
Finally someone comes along, extracts the concepts from the mess, makes
everything nice and orthogonal and small. Then the cycle starts over,
trying new ideas on top of the old ones and making a mess (but learning a
lot of new good stuff in the process). Personally, it seems like UNIX
became generally known (in the V6/PWB/V7 time frame) when it was a fairly
tight, clean system. 4.2 is out on the limb of a lot of experiments. It's
time to admit that some of the ideas didn't work and the rest need cleaning
up.
Perhaps the biggest mistake made with 4.2 is the attempt to treat it,
unmodified and not carefully debugged, as a production system. That
mistake can hardly be laid completely at Berkeley's door, by the way.
People who just port 4.2 to their machine without any tuneup, cleanup, or
bug fixing are asking to be seriously embarrassed.
> What are other's thoughts? Was all the trouble worth it? Should
> further work proceed from a 4.1 base? A system V base? Or what?
If any more Research systems see the light of day, we might find another
base for development there. Someone MIGHT even consider taking the
concepts and starting over from scratch. It's been done before:-)
--
Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086
...A friend of the devil is a friend of mine.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!houxm!whuxlm!akgua!
mcnc!decvax!genrad!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!
From: M...@brl-tgr.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <7552@brl-tgr.UUCP>
Date: Sat, 19-Jan-85 02:03:20 EST
Article-I.D.: brl-tgr.7552
Posted: Sat Jan 19 02:03:20 1985
Date-Received: Thu, 24-Jan-85 07:02:15 EST
Sender: n...@brl-tgr.UUCP
Lines: 25
No, it's not a failure.
BRL has measured filesystem performance improvements of 7X for
various graphics applications, and it REALLY HELPS.
I regularly see DELIVERED USER DATA in excess of 500 Kbytes/sec
sustained for > 10second bursts off of our Eagles on the SBI on
a 780. No complaints here.
I submit that Doug Gwyn's relative ease of implementing his
System V-under-4.2 BSD package tells you quite a bit about
the relative differences.
SUMMARY. Both System V and 4.2 are still UNIX. System V has
lots of emphasis on good user utilities and massive
user documentation. 4.2 has emphasis on performance and networking.
If you don't need networking or performance, System V is the clear
winner. If you have more than a few machines, networking is hard
to live without.
NOW LETS CANCEL THIS DISCUSSION -- net.unix-wizards IS FOR MORE SERIOUS
TOPICS THAN THESE INTERMINABLE PHILOSOPHICAL DISCUSSIONS.
-Mike Muuss
UNIX-WIZARDS Moderator
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site wdl1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!dual!amdcad!
fortune!wdl1!jbn
From: j...@wdl1.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <215@wdl1.UUCP>
Date: Mon, 21-Jan-85 21:24:20 EST
Article-I.D.: wdl1.215
Posted: Mon Jan 21 21:24:20 1985
Date-Received: Thu, 24-Jan-85 06:58:57 EST
Sender: no...@wdl1.UUCP
Organization: Ford Aerospace, Western Development Laboratories
Lines: 68
Nf-ID: #R:wdl1:17100032:wdl1:17100051:000:3020
Nf-From: wdl1!jbn Jan 21 12:13:00 1985
4.1BSD is a very stable system. Below is our /usr/adm/shutdownlog for
the last six months or so, all on an original-release 4.1BSD system with
UNET networking. No panics other than machine checks; most of the the
shutdowns shown below are for scheduled hardware or software service.
The machine is a 4MB VAX 11/780 with four CDC9766 disk spindles, supporting
about twenty users at a time. (This is host FORD-WDL1.ARPA on the Internet.)
Is anyone getting this level of stability with a 4.2BSD system?
Reports on ULTRIX would especially be appreciated.
Perhaps there should be a newsgroup for exchanging uptime/downtime
data.
09:07 Mon Aug 13, 1984. Reboot
09:28 Mon Aug 13, 1984. Reboot
16:00 Fri Aug 17, 1984. Shutdown: Going down for network fixing. Back up in 1/2
hour (by jrb)
16:00 Fri Aug 17, 1984. Halted.
16:19 Fri Aug 17, 1984. Reboot
00:04 Sun Aug 26, 1984. Reboot
16:00 Mon Aug 27, 1984. Shutdown: system is going down for DEC repair (by root)
16:00 Mon Aug 27, 1984. Halted.
16:56 Mon Aug 27, 1984. Reboot
22:49 Mon Aug 27, 1984. Shutdown: Reboot for network system (by root)
22:49 Mon Aug 27, 1984. Halted.
23:10 Mon Aug 27, 1984. Reboot
14:07 Thu Sep 6, 1984. Reboot
09:18 Mon Sep 10, 1984. Shutdown: DEC PM service (by root)
09:18 Mon Sep 10, 1984. Halted.
10:39 Mon Sep 10, 1984. Reboot
17:59 Mon Sep 10, 1984. Shutdown: SYSTEM TROUBLE (by root)
17:59 Mon Sep 10, 1984. Halted.
11:29 Tue Sep 11, 1984. Shutdown: Going down for memory testitg (by root)
11:29 Tue Sep 11, 1984. Halted.
12:39 Tue Sep 11, 1984. Reboot
04:06 Wed Sep 19, 1984. Reboot
12:56 Tue Sep 25, 1984. Shutdown: (by root)
12:56 Tue Sep 25, 1984. Halted.
13:14 Tue Sep 25, 1984. Reboot
09:36 Sat Oct 6, 1984. Shutdown: For System Maintenance (by root)
09:36 Sat Oct 6, 1984. Halted.
00:50 Sun Mar 10, 1985. Reboot
21:46 Sun Oct 7, 1984. Shutdown: New Unet system (by root)
21:46 Sun Oct 7, 1984. Halted.
22:04 Sun Oct 7, 1984. Reboot
09:32 Mon Oct 8, 1984. Shutdown: DEC PM (by root)
09:32 Mon Oct 8, 1984. Halted.
10:01 Mon Oct 8, 1984. Reboot
10:03 Mon Oct 8, 1984. Shutdown: (by root)
10:03 Mon Oct 8, 1984. Halted.
11:38 Mon Oct 8, 1984. Reboot
06:51 Thu Oct 11, 1984. Reboot
21:08 Fri Oct 19, 1984. Shutdown: Tape drive hung (by root)
21:08 Fri Oct 19, 1984. Halted.
21:27 Fri Oct 19, 1984. Reboot after panic: mchk
08:41 Mon Oct 22, 1984. Shutdown: DEC Maintenance (by root)
08:41 Mon Oct 22, 1984. Halted.
02:33 Sun Mar 10, 1985. Reboot after panic: mchk
09:05 Tue Nov 20, 1984. Shutdown: (by root)
09:05 Tue Nov 20, 1984. Halted.
12:22 Tue Nov 20, 1984. Reboot after panic: mchk
13:36 Tue Nov 20, 1984. Reboot
13:35 Wed Dec 5, 1984. Reboot
02:29 Thu Dec 6, 1984. Reboot
09:33 Mon Dec 10, 1984. Reboot
11:59 Mon Dec 17, 1984. Reboot after panic: mchk
11:21 Wed Jan 16, 1985. Reboot
23:58 Thu Jan 17, 1985. Shutdown: Reboot with larger system (by root)
23:58 Thu Jan 17, 1985. Halted.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 11/03/84 (WLS Mods); site astrovax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!wls
From: w...@astrovax.UUCP (William L. Sebok)
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <533@astrovax.UUCP>
Date: Thu, 24-Jan-85 01:20:08 EST
Article-I.D.: astrovax.533
Posted: Thu Jan 24 01:20:08 1985
Date-Received: Fri, 25-Jan-85 05:06:24 EST
References: <215@wdl1.UUCP>
Organization: Princeton Univ. Astrophysics
Lines: 15
>
> 4.1BSD is a very stable system. Below is our /usr/adm/shutdownlog for
> the last six months or so, all on an original-release 4.1BSD system with
> UNET networking. No panics other than machine checks; most of the the
> shutdowns shown below are for scheduled hardware or software service.
> The machine is a 4MB VAX 11/780 with four CDC9766 disk spindles, supporting
> about twenty users at a time. (This is host FORD-WDL1.ARPA on the Internet.)
> Is anyone getting this level of stability with a 4.2BSD system?
> Reports on ULTRIX would especially be appreciated.
We are. We have much less software related crashes now under 4.2 BSD than
when we were running 4.1 BSD a year ago.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Fortune) 6/7/84; site dmsd.UUCP
Path: utzoo!dciem!nrcaero!pesnta!hplabs!hpda!dmsd!bass
From: b...@dmsd.UUCP (John Bass)
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <158@dmsd.UUCP>
Date: Sat, 26-Jan-85 06:11:19 EST
Article-I.D.: dmsd.158
Posted: Sat Jan 26 06:11:19 1985
Date-Received: Mon, 28-Jan-85 02:15:29 EST
References: <7552@brl-tgr.UUCP>
Lines: 143
Is 4.x a failure ... NO
IS 4.x a high performance system ... MAYBE YES and MAYBE NO
People forget that 4.1 and 4.2 were paid for and tuned for AI Vision and CAD/CAM
projects sponsored by ARPA and various compainies. For the job mix that 4.x
systems are tuned for it is the ONLY way to do those jobs on a UNIX machine
with any cost effectiveness.
Many tradeoffs that go into 4.x systems are directly counter the best ways
to tune UNIX systems for development environments ... but they were the
only way to make things work for the target applications.
The converse is also true to a large extent ... V7/SIII/S5 kernels don't
handle large applications well or at all --- try running a 6mb application
on an older bell system with swapping .... it takes many seconds for a
single swap in/out.
But exactly the same problem arises out of blindly using a paging system for
the typical mail/news/editor/compiler type support or development machine.
In this environment the typical job size is 5-50 pages with an 75-95% working
set ... when the total working set for the virtual address space approaches
the real memory size on a 4.x system running these small jobs the system
goes unstable causing any program doing disk I/O loose one or more critical
pages from it's working set while it waits for its disk i/o (either requested
via a system call ... or just from page faulting).
The result is a step degradation in system throughput and an interesting
non-linear load curve with LOTS of hysterisis AND a sharp load limit at
about 150-250% of real memory. In comparison a swap based system linearly
degrades smoothly at 1/#users for most systems ... up to a limit. On
Swap based systems if the swap in + swap out time excedes the scheduling
quantum (several seconds on most unix systems) then even a swap based
system can trash and show a simular step degradation, non-linear load curve,
hysterisis, and the load limit. This was evident on ONYX because the
burst disk thruput was limited by the z80 controller to a 3:1 interleave
or about 180kb/sec .... memory was relatively cheap compared to fast disks
in 1980 so we sold lots of memory.
This was evident on the Fortune VAX running 4.1 after several months of
intensive load analysis tracking load factor results and instrumenting
the disk subsystem. 4.1's favorite trick is to have a step increase in load
factors from between 1-4 to 10-20 with little time any where in between.
On the Fortune Vax this was caused by an interaction between paging and
filesystem traffic on the root spindle when the average service time
in the disk queue exceded the memory reapers quantum. A careful policy
of relayout of the filesystems and regular dump/restore of filesystems to
keep them sequential and optimally packed kept teh filesystem (read disk
subsystem) thruput high enough the step degadation (step increase in load
factors) would not occur and we then seldom saw load factors of 10-20, and
only then with a linear rise in load. I have seen the same problem on
most other 4.1 systems ... particularly those with a single spindle and
small memory configurations (less than 2mb).
Most vax systems run 35-50 transactions per second average to the entire
disk subsystem ... a swap system handling a 40k process will typically take
one/two transactions ... a paging system 40 or more depending on the thrashing
level. The working set theory CORRECTLY predicts such poor behavior for
such small programs with large percentages of active pages. If it is required
to run several very large images (CAD/CAM, vision or other high res graphical
application) with 2-8 mbyte arrays ... then the working set theory combined
with processor speed/memory size predictors make paging a clear choice.
Much of the speed difference of 4.1 over v7 and SIII/S5 was simply the
1k filesystem. For older PDP11's the per block processing time for most
512 byte sectors was several times the transaction period .... IE ...
it took several 6-10 milliseconds of cpu time to digest a block which
was tradedoff against filesystem thruput and memory constraints of 256kb
max system size. The advent of much faster processors and much larger
system memory made using 1k blocks necessary and practical where your
system didn't have the cycles or space before. For those of us
mothering 11/45's in the 70's this was a very difficult tradeoff ...
we had kernels of about 70kb leaving less than 180kb to support 2-6 incore
processes/users ... or in todays terms ... nor more than 2/3 happy vi users.
increasing the filesystem size to 1k would increase memory overhead by
6-10k in the kernel and 2-4k in each process ... or ONE LESS VI DATA/STACK
segment --- a major reduction in the number or incore jobs 30-50% and much
more swapping and response time delays.
Today with relatively cheap ram ... only the smallest systems need worry
this problem ... and then a mix of swapping (for jobs less than 150-500kb)
and paging (for jobs greater than 150-500kb) will make most of these
problems go away.
As for the 4.2 "fast filesystem" ... it was again tuned to make large file
transaction run at an acceptable rate .... try to load/process a 4mb vision
or cad/cam file at 30-50 1k block transactions per second -- it will run
SLOW compared to a production system with contigous files. A number of
tradeoffs were made to help large file I/O and improve the transaction
rates on very loaded systems (LIKE ucb ernie ... the slowest UNIX
system I have ever used .... even my 11/23 running on floppies was
faster). But for most of us -- particularly us small machine types ..
PDP11/23's, 11/73's, ONYX's, Fortune's, Tandy 16B's ... and a number of
other commercial systems (including VAX 11/730, 11/750, and micro vaxs)
which run 1-8 users ... the 4.2 filesystem is VERY SLOW and gets SLOWER
much faster over time than a v7/4.1 filesystem.
The tradeoff here is that "locality of reference" is much smaller and well
defined on smaller systems ... on larger systems (like ernie) the disk queue
has a large number of requests spread across the entire disk with a much
broader locality of reference. The 4.2 filesystem attempts to remove
certain bimodal or n-modal access patterns based on the FACT it doesn't
much mater where the data is for reading ... but it is better to write
it without generating a seek .... for systems with large disk request
queues. This doesn't hold up on small systems where much of the
time there is a single active reader using the disk subsystem.
On the small system locality of reference is the entire key to throughput,
thus randomly allocating files wherever is a great loss.
I have spent most of my 10 years of UNIX systems hacking, porting and tuning
on smaller systems. Other than CAD markets I don't see much use for paging
systems, and as a result view 4.1/4.2 as only a hinderance due to the tendancy
of some firms to put all the bells and toys into their system. This has
been a disaster for several firms who got side tracked by Berkeley
grads and hangers on.
But in the big system markets ... particularly CAD/CAM, highres graphics,
large multiuser system (30-200 users), and AI/Lisp markets 4.2 may be the
only alternative ... it would be a mistake to drag the standard unix
blindly down the 4.2 path ... 99.99% of the unix systems either delivered
today or built in the next couple years would be hurt badly by it.
It would make the number one alternative to UNIX on smaller systems
ONLY MSDOS -- not such a bad system ... but lets keep it in its place too.
I have a lot of interesting numbers and recomendations in performance areas ...
I was going to give them in a talk at Dallas but they saw fit to cancel
it after requireing a formal paper for the unplanned proceedings without
any notice ... and then having a two page draft lost in the mail.
I don't feel to bad about it since appearently 8 other speakers were
also accepted and dropped because they couldn't get papers written and
approved in the several day to 2week window. I hope that next time they
put out a call for presentations USENIX lets people know in advance
papers are required and don't change the rules in the 11th hour if they
say they are not. Most of us can't write a GOOD 5-10 page paper with a
24 hour deadline which is basiclly what they asked of speakers this time --
other than those who had already done a paper for some reason.
Good nite ... have fun
John Bass
Systems Consultant
(408)996-0557
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site grendel.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!grendel!avolio
From: avo...@grendel.UUCP (Frederick M. Avolio)
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <419@grendel.UUCP>
Date: Sat, 26-Jan-85 10:19:03 EST
Article-I.D.: grendel.419
Posted: Sat Jan 26 10:19:03 1985
Date-Received: Mon, 28-Jan-85 07:07:15 EST
References: <215@wdl1.UUCP>
Organization: DEC ULTRIX Applications Center, MD
Lines: 17
> Is anyone getting this level of stability with a 4.2BSD system?
> Reports on ULTRIX would especially be appreciated.
Yes, we are on our Ultrix-32 system on a VAX-11/750. We throw away
the up/down log periodically, so from memory -- in the 6 or 7 months I
have been using the system (it has been around longer than I) it has
crashed 5 or 6 times when the power went out due to thunderstorms
(each time it rebooted, fixed the file system errors, and came up on
its own). It also crashed twice due to hardware errors in the disk
controller causing hard errors all over the disks. (This was fixed by
powering them all the way down and then back up again. I don't claim
to understand it...:-))
--
Fred Avolio
301/731-4100 x4227
UUCP: {seismo,decvax}!grendel!avolio
ARPA: grendel!avo...@seismo.ARPA
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: Is 4.2BSD a failure?
Message-ID: <5004@utzoo.UUCP>
Date: Sat, 2-Feb-85 20:20:20 EST
Article-I.D.: utzoo.5004
Posted: Sat Feb 2 20:20:20 1985
Date-Received: Sat, 2-Feb-85 20:20:20 EST
References: <7552@brl-tgr.UUCP>, <158@dmsd.UUCP>
Organization: U of Toronto Zoology
Lines: 16
Keywords: 4.2BSD, file system
Actually, we came up with a rather different idea about why 4.2BSD's
"fast file system" gives such disappointing results in practice. It
expends quite a bit of effort to try to keep related blocks on the same
cylinder (or nearby). However, note that related blocks are seldom
accessed simultaneously; there is usually some processing delay in
between. Keeping related blocks near each other is a win *only* if
the disk heads will probably still be in the vicinity when the next
access occurs. And... the 4.2BSD filesystem benchmarks were all run
*single-user*!!! So of course it's nowhere near that good when a
dozen other processes are competing for the disk heads. The speed
improvements that *are* seen are probably mostly just a result of
bigger blocks. We conjecture that the "cylinder group" approach
is of little or no benefit for orthodox multi-user time-sharing.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry