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" _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
