[OpenAFS] extreme slowness on windows client

[David Bear]

On Wed, Jun 28, 2006 at 12:49:53PM -0400, Jeffrey Altman wrote:
> David Bear wrote:
> >> Follow the instructions in the OpenAFS for Windows release notes.
> >> Use the SysInternal's FileMon and DbgView tools to figure out what
> >> requests Windows is making and map them to the internal processing
> >> in the AFS Cache Manager to figure out why they are taking so long
> >> to complete.
> > 
> > well, this may be the only way, but it won't work. Both these systems
> > are used constantly by their primary users. I can't send them home for
> > a day while I do this.
> 
> You can configure the monitors to log to a file and come back at
> the end of the day and grab the files.  Minimal impact on your users.
> 
> Or you can bump the log level on your file servers and monitor
> the traffic from that side of the world.
> 
> > Are there any other known interactions that could be a problem?
> 
> There are lots of known interactions that are problems:
> 
> (1) clients that change their addresses or port numbers when
>     communicating with pre-1.4.2 files servers will result in
>     delays of 57 seconds each time the file server detects a
>     change and there is a callback that is waiting to be revoked.
> 
> (2) the windows client doesn't implement inline bulk status updates
>     so performance is horrible when evaluating the contents of
>     directories when there is only 'lookup' privilege.
> 
> (3) you could be suffering from a bug in the client that results in
>     a deadlock on one or more stat cache entries
> 
> To be more helpful you will have to provide many more details:
> 
> (1) exactly which release did you install on the windows client?
> 
> (2) what version are your file servers?
> 
> (3) your new dynamic addresses, do the client machines get the same
>     addresses each time?
> 
> (4) what operations are your users performing that are failing?
>     (this you will get from the file monitor logs)
> 

I solve the problem -- but I never diagnose the issue nor did I
control my changes to the system to see which really affected openafs.

I solved it by

1) removing checkpoint
2) removing openafs
3) reseting the ms tcpip stack using the netsh command.
4) reloading openafs
5) reloading checkpoint

After doing that -- openafs was snappy and worked well.

> 
> Jeffrey Altman



-- 
David Bear
phone: 	480-965-8257
fax: 	480-965-9189
College of Public Programs/ASU
Wilson Hall 232
Tempe, AZ 85287-0803
 "Beware the IP portfolio, everyone will be suspect of trespassing"