Lars Schimmer wrote:
1. slowness - Users reports of LONG loading times for 400-1000 MB roaming profiles, up to 20 minutes
How large is your cache? If your cache is smaller than what you are loading all you are doing is repeatedly thrashing the contents of the cache. That will result in the worst possible performance. OpenAFS must be tuned for your environment. The defaults 96MB of cached data, 10,000 status cache objects, 5000 volumes, 2500 cells are not right for everyone. They are simply reasonable defaults. The max cache size of 32-bit Windows is system dependent but will be somewhere between 800MB and 1.2GB. For 64-bit Windows the limit is 512TB.
2. as in computergraphic, we handle 10-400 MB models with our programs. Getting this via the fileserver at 5-6 MB/sec is kinda slow.
Faster network?
The cache on AFS is written as a single file, I would prefer a partition as it can't be defragmented
The cache is a paging file. As with any file it cannot be defragmented while in use. You can stop the afs client service and defragment the file if desired. The file is also allocated entirely at the same time
so if there is contiguous space at the time of allocation there will be no need to defragment it later. You can choose where you want the paging file to be located. If you want to put it on its own partition you can do so.
3. reliability - some days windows hit a error while saving the profile and no "readable" info could be found - I assume mostly unicode problems
need more details.
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 problem
provide 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?
smime.p7s
Description: S/MIME Cryptographic Signature
