Matt, Thanks for the response. At least I'm not alone in seeing this issue. Our machines are all desktops that have fixed addresses and don't hibernate so we may be seeing the same issue manifesting in different ways.
Jeffrey, We had this issue occur again today on a machine and we did try the "fs flushall" command but it didn't correct the issue. Unfortunately, this was on a staff machine and the person needed to use it so I couldn't do any proper debugging. I'll look into setting up a test machine and see if I can reproduce the behavior there and then get debugging information to submit. -- Russ Howard -----Original Message----- From: Matt W. Benjamin [mailto:[email protected]] Sent: Tuesday, November 25, 2014 11:48 AM To: Jeffrey Altman Cc: Howard Jr, Russell A; [email protected] Subject: Re: [OpenAFS] Anyone else experiencing a cache bug in 64-bit OpenAFS for Windows 1.7.3200? Hi, I run into "this" frequently on my Win 7 (64-bit) laptop. I had a sense the problem might be related to changing networks and hibernation, but shamefully I haven't made any real effort to root cause it. In my random attempts to deal with it, I found that reboots (usually more than one) helped. It hadn't occurred to me to try flush the cache, I will remember to try it next time I see this. Thanks, Matt ----- "Jeffrey Altman" <[email protected]> wrote: > 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 the first report I have heard about it. -- Matt Benjamin CohortFS, LLC. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://cohortfs.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309
