Lars Schimmer wrote: > Jeffrey Altman wrote: > I like to mention my/our side of view: > The OpenAFS windows clients went better and faster from release to > release. I still remember old 1.3.x times, in this view, the 1.5.28 is > really far better and faster. > And I don't want to smaller the work of the dev team and the work that > has been done. > > We use OpenAFS on 10-20 windows workstations with integrated logon and > user profile in OpenAFS filespace. > > Problems mentioned by users: > 1. speed - although in the 4-10 MB/sec area, we are working in graphics > area and handling with 1-500 MB models. Some folks wish to obtain higher > rates - I wait for direct windows drive instead of smb/cifs binding > before I mourn about speed problems ;-) > And the biggest problem with speed is windows itself - loading/saving a > 1GB profile is damned slow, doesn't care if it is on win 2003 server > local space or in OpenAFS space. So no bad point for OpenAFS - If loaded > daily I assume OpenAFS is faster while loading than win 2003 server > local space.
While AFS on UNIX is limited by the performance of Rx/UDP, on Windows we are actually limited by the CIFS/SMB implementation. A native redirector will be a big win here. > 2. Load/save problems with some programs > e.g. I had the problem on one pc with office we tried to solve with > Jeffrey Altman, still no luck. OpenAFS seems to do all right, office > not. It just waits for 30-120 sec until it opens a file and windows is > blocked in that time - solved for that PC with a complete system > reinstall and working with a local copy of office files and "backup" > local changes into OpenAFS filespace. > I just want to note, on my laptop and private PC I can work with that > office files out of OpenAFS space with no problem at all, but I don't > use office as much as the noted PC/user. > > And latest exampel is DeepExploration 5 - don't know why but open a file > out of OpenAFS works, saving that loaded file let DeepExploration went > mad and do nothing more... > And sry, til yet no time to debug that issue, but I think it is DE which > went mad and OpenAFS seems to do all right. Most of the saving problems we have seen with Office in the past are due to the Windows CIFS client timing out the connection to the AFS Client Service. Another area where the native redirector will be helpful. > 3. Encoding of names, NTFS-nondata-streams, big files support > I know, that will be implemented with win native drive support, but I > just wanted to note, my users try to use OpenAFS like a normal drive and > sometimes hit theses problems. You have big file support now. What issues are you having? As for the others, UNICODE support with come with the native redirector. Multiple data streams can't be implemented without changes to the file server and volume formats. > But one point is: it IS reliable for me, as soon as data is on AFS > server (I use one RW copy and at least 2 RO copies). > Til yet no problem with data loss or changed data or else. > Even the "bad" win 1.5.22-1.5.25 worked flawless. > If data got on server, its reliable and secure. Getting data into > OpenAFS is sometimes tricky (e.g. DeepExploration), most times as easy > as local drive. Rodney's complaint about reliability was not about the file servers but about the clients. If a user can't save their work from the application they are using and the application crashes as a result, then the AFS client is unreliable. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
