On 11/25/2014 10:22 AM, Howard Jr, Russell A wrote: > Since October, I’ve been doing upgrades and new installs of the OpenAFS > Client using 1.7.3200. We’ve recently encountered what appears to be a > cache-related bug in this version but I haven’t found a way to reliably > reproduce it. All clients are running Windows 8 x64 Enterprise as the OS. > > When the error occurs, it presents itself by the user seeing the > following message when trying to access any mapped AFS drives (“M” in > this case): > > M:\ is not accessible. > > The name of the file cannot be resolved by the system.
This error can be generated from at least a thousand different causes. The Release Notes that ship with the client include debugging instructions that will help you identify the cause of the problem. > In order to restore AFS access on the machine, I had to stop the AFS > Client service, remove the cache file, and restart the service. Stopping the service will leave the kernel in an inconsistent state which can result in data corruption. A reboot of the system should be performed at the earliest opportunity. There are many "fs" commands for manipulating the state of the cache manager fs checkservers fs checkvolumes fs flush fs flushvolume fs flushall or examining the state fs examine fs memdump That should be used in preference to stopping the service. In particular, if you believe the problem is related to bad state information being stored in the AFSCache file then the "fs flushall" command would invalidate all of it without a service stop. > This is > only a temporary fix as we’ve had several users experience this issue > multiple times. Since this appears to be a reoccurring problem, > yesterday I tried a different approach. On a machine that was failing, > I removed 1.7.3200, rebooted, installed 1.7.3100, and rebooted again. > This was done without clearing the AFS cache and it restored AFS access. Rolling back a version of the software will re-initialize the AFSCache file on next start. The changes between 1.7.31 and 1.7.32 are almost exclusively to the file system driver components. The one area of change to the service is suspend/resume power management processing related to VL and FILE server state probing. This information is not stored in the AFSCache file. > Has anyone else encountered this problem? This is the first report I have heard about it.
smime.p7s
Description: S/MIME Cryptographic Signature
