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)
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
