[2795] in testers
sun4 7.7O: AFS/kernel
daemon@ATHENA.MIT.EDU (Craig Fields)
Sun Jan 29 20:13:08 1995
To: testers@MIT.EDU
Cc: probe@MIT.EDU, miki@MIT.EDU
Date: Sun, 29 Jan 1995 20:12:02 EST
From: Craig Fields <cfields@MIT.EDU>
System name: perilous
Type and version: SPARC/Classic 7.7O
Display type: cgthree
What were you trying to do?
cd /afs/dev.mit.edu/reference/solaris_2_3_src
find . -type f -print >& /tmp/FILES
What's wrong:
On a normal (not January patch, older AFS) Sun it takes
ten minutes.
It took around five hours on perilous. For the first couple
of hours of this, I was doing pretty low-load operations
(on the order of reading manual pages). Later, I went home.
Once the find had completed, my machine was hosed big time.
(I had left the find running, and returned several hours after
it completed.) From the output of top:
Cpu states: 0.0% idle, 1.2% user, 21.4% kernel, 38.7% wait, 38.7% swap
The performance was utterly in the toilet; I could hear the
machine swapping its brains out. I never managed to wait long
enough to change window focus, it took at least five minutes
to raise a window after I pressed the key bound to do it, and
I could see that the xterm cursor is drawn with vertical lines
from left to right.
There were no user processes still running to cause this.
There's a core in /var/crash/perilous; Richard, you're still
in root's .klogin, if a core will do you any good. I did an
L1-A; 0 set-pc; go (couldn't figure out another way to do it,
worked this out with jhawk)
I tried to reproduce the problem on davis, but all I got was
a big perfomance hit. It took 1:45 to complete the find, as
compared to ten minutes... Still an order of magnitude.
What should happen:
We need to fix this, or I think we need to back it out of
the patch release. Unfortunately, the patch release is supposed
to hit the field in a couple of days, which doesn't leave much
time to find the problem... We also need to see if this problem
applies to the RS/6000 and act accordingly.
