[OpenAFS] klog really slow (Fedora Core Linux, kernel-2.6.14-1.1656_FC4)

[Paul Johnson]

Our Sysadmin built an openafs server with very much storage and he
says Windows clients access it without delay.  On my Linux systems,
however, I observe some very strange/sluggish behavior.  And I don't
know if the problem is in the kernel, or my authentication setup, or
in openafs-client.

I installed openafs by taking your openafs-1.4.0-1 src.rpm file and
rebuilding so it created the kernel module.  After making the
configuration changes in /usr/vice/etc and starting the services, I
*guess* I did everything necessary.  I made no other configuration
changes.

When I type

$ klog pauljohn

the system waits for between 40 and 50 seconds. THere are no errors,
and eventually the klog is approved.  The connection is good and I can
move files in and out of /afs/ku.edu, our cell.

This reminded me of a problem related to firewalls that I have with
email sometimes.  The email system tries a reverse lookup and if my
firewall is not opened, then it waits a while, then goes ahead.  But I
turned off my firewall entirely ("service iptables stop") and the klog
was still really slow.

How to debug?  Is there some program I could get to monitor what's
going on while klog is working?

I've searched openafs email archives and see some people mentioning
stale connection information making klog run slow, but this happened
on my first connect.

Perhas this is related, but perhaps this is a completely separate
problem.  Sometimes file access stops abruptly and then restarts a
minute or so later, and the end of the dmesg output says:

 pols110 kernel: afs: Lost contact with volume location server:

$ fs checkservers
All servers are running.

What do you think?  In the startup information, from var log messages,
I do find this warning about the "system call table":

ip_conntrack version 2.3 (4084 buckets, 32672 max) - 236 bytes per conntrac=
k
openafs: module license 'http://www.openafs.org/dl/license10.html'
taints kernel.
Warning: failed to find address of system call table
System call hooks will not be installed; proceeding anyway
Starting AFS cache scan...<6>tg3: eth0: Link is up at 10 Mbps, half duplex.
tg3: eth0: Flow control is off for TX and off for RX.
found 935 non-empty cache files (9%).
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]

What do you think?


--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas