Lars Schimmer wrote:
3. reliability - some days windows hit a error while saving the profile and no "readable" info could be found - I assume mostly unicode problemsneed more details.Right now such a special "user profile". Win client 1.5.3009 (fresh installed today, 400 MB cache, Windows XP SP2) and user profile in AFS space, one RW, 3 RO and a backup volume, all on OpenAFS fileserver 1.4.6 on debian. On that special workstation the administrator, my personal user and my testuser can login and logout without any problems. That user has a 200 MB user profile, login works fine (I assume out of local copy) but while logout it waits for at least 10 min, hit a error "file could not be copied, network unaccessible" aftr click on OK, it just tells me "roaming prfile unaccessible" and I could login as other user. To be more exact: while login, it obtains tokens, user got a valid token and can browse AFS space and even his profile in AFS space. After the logout hung, I logged in as admin and did a fs trace -dump, maybe it can be helpful, where to send it to?
What would be more useful is a log from SysInternals procmon. You are trying to determine why Windows failed not OpenAFS. More than likely I'm going to guess one of two things occurred. Either a file that could not be written to the network due to a name issue was encountered or the CIFS client timed out the connection to the AFS client because the AFS simply could not write the file to the AFS file server fast enough to keep up with the data being written by the logout. Remember, your cache is smaller than your largest data file. The file can't fit in the cache therefore the cache manager is forced to recycle buffers for each and every write.
4. the context menu - nearly all workstations has it disabled as it "send the explorer into a timeout" - from 1.5.x on til now for the most active win users the context menu is a problem - right click on a file OUT of AFS space keep the system freeze for ~60 sec til the context menu appears. For files in AFS space it appears direct. Til yet I haven't found any solution why it freezes, as in all my test accounts it just doesn't appear, even on workstations on which the other users have that problemprovide a system this can be replicated on that is accessible via remote desktop and which has debugging tools for windows installed.You are not the first to mention this but no one has ever followed up with a system on which the problem can be replicated. I can't replicate the problem therefore I can't fix it.The explorer shell makes the equivalent of the call "fs whereis <object>" with the current directory being the folder that is active in Explorer. Does this command when executed from the command prompt experience the same delay?Problem is, it just happens with some users, not with all. I try to get a user with that problem in which no sensible data is reachable/activated. And it seems like the fs whereis doesn't show that delay, at least not for that user in which context menu problem appears.
Which makes me wonder. Is this really a problem with AFS? Or is there some other AFS shell extension or security software that is trying to protect the user. For example I can easily imagine a privacy / adware product that would block network requests triggered by access to the local disk by an Explorer extension because they believe that the network request must be an unwanted behavior. \\AFS appears to be a remote CIFS file server on the surface. ---- another thing I forgot to mention about tuning is that if you are on a local network and you are dealing with really large files you should consider increasing the chunksize with which the AFS client reads data from the file servers. Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
