Hi Sean, I can't release too many details about how we're using OpenAFS, although I can say that it's a great tool for sharing data between distant locations. OpenAFS in general seems fairly stable once you have it configured properly, although there are some points which I believe are worth considering before comitting oneself to it.
First, performance in general is not going to be as good as NFS for read/write data on the local network. With the 1.2 series clients, performance was actually rather terrible in our configuration for a single client. The 1.3 series seems to have come a long way toward fixing this, although write performance is still slower than NFSv3. OpenAFS has file locking semantics which seem to strongly favor reads over writes. Second, OpenAFS doesn't seem to work very well with NATs. This seems to mostly be an artifact of it being a UDP-based protocol. If you have a lot of clients behind NATs, OpenAFS may not be suitable for your use. The developers do not seem to be interested in a solution for this at the moment, although to be fair there are a number of other things they are working on. Third, client support for newer platforms has improved since we started using it but it isn't perfect yet. OpenAFS seems to just now be stabilizing on the Linux 2.6 series kernels in the newer 1.3 releases. Older releases of OpenAFS don't support 2.6 at all with PAGs to my knowledge. I wouldn't recommend running a pre-release filesystem (or pre-relase anything) on production systems. OS X support seems good all around, but tends to come out a while after each new release of the OS. As for the previously supported platforms, Solaris support seems good enough. We haven't had any complaints about it yet. We have no HP-UX systems to test it on, so I can't comment on that. The Linux 2.4 client works as well as any of the other clients, with big performance improvements coming along in the 1.3 series. The Windows 2k/XP client has definitely come a long way, although it's not yet ready for our network. The Windows issue is probably due to our network configuration, and may not apply to you. Windows isn't critical to our use of AFS though. Fourth, backups can of course be interesting due to the way OpenAFS stores files. The included backup system will take some scripting if you want to use it reasonably. I've been able to make it work well enough, but you might be better off with a third party backup solution if you don't want to invest a lot of time in it. As with any new service, the best thing you can do is test, test, test. I'd advise making your own test cell to ensure that you're comfortable with the management interfaces. It's also good to have documented recovery mechanisms before going forward with an implementation. Regards, Lester Barrows On Friday 12 August 2005 14:15, Sean Kelly wrote: > I've been stalking this mailing list for a few months now while pondering > the possibility of deploying an AFS setup in my environment. However, while > reading this list I've not been able to get a firm idea of how stable > OpenAFS is. > > There seem to be a lot of reports about OpenAFS causing many Linux kernel > panics, having issues with newer or older kernel versions, random > configurations, or just instability in general. Is this because OpenAFS > really is a very sensitive program/service, or is it the standard problem > of only hearing from those who are having a problem? > > Does OpenAFS work with RHEL AS 4? RHEL AS 3? HP-UX and Solaris? > > I'd be interested in hearing an in depth description of how people are > using AFS both in commercial and educational environments today and their > success and failure stories. I realize AFS has been around for a long time > and do have the _Managing AFS_ book, but I'd be curious if things have > changed in the post-TransArc era. > > Thanks! _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
