Something else I will point out as it has been a problem in the past. The Windows cache manager unlike the UNIX cache manager preserves its UUID across restarts. This UUID is preserved in the AFSCache file but can be changed with
fs uuid -generate I don't know what file servers you are using but there have been bugs in the file server host tables in the past that would effectively blacklist a client until its UUID was changed. The fact is that this user's problem could be anything. A drive letter is mapped to a UNC path. That UNC potentially crosses multiple mount points requiring access to multiple file servers. Some of those paths might require authentication with valid tokens. The evaluation of each path component requires interactions with all network providers installed on the system, the multiple UNC provider, the AFS redirector file system driver, the afsd_service, and the file servers. Plus anything in between the client system and the file server. Until the actual failure is isolated issuing commands is like taking a black box and . kicking it . punching it . hitting with a hammer and hoping that something changes. Jeffrey Altman On 11/26/2014 9:37 AM, Howard Jr, Russell A wrote: > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
