Is OpenAFS Robust Enough to Replace NFS?

eskimoe asks: "Has anyone been playing with (OpenAFS) lately? It looks very promising and claims to be kinda stable now. Unfortunately Google didn't find any reviews when I last searched. This surprised me, considering what I would suspect to be a not-so-small percentage of sysadmins who would absolutely love a secure, not-as-broken-as-nfs, not-depending-on-braindead-RPC-stuff, not-relying-on-client-for-authentication network file system. The other available alternatives such as CODA, various nfs-patches/branches (generally addressing one NFS design-bug at a time while causing more problems) or SMB-only environments have never reached the state of functionality and usability necessary to actually become a serious NFS-killer. So, would you deploy AFS in a production environment, yet? Has anyone tried?"

Comments

AFS is good

[mattdm]

We use (commercial) AFS extensively at Boston University. We've historically had some trouble with getting updated client software for new operating system versions in a timely matter, so OpenAFS is pretty exciting to us. We have been using arla as our Linux client, but unfortunately have some serious reliability issues, so we've been testing OpenAFS and will probably ship that in the upcoming BU Linux 2.0.

Using it in production since February...

[Colitis]

We have a couple of hundred dual-boot workstations
with around 700 total users. So far it's proven to
be *more* reliable than NFS; we've had one
occasion where the server had to be rebooted due
to a non-responsive state. Current uptime is 120
days, with not a hiccup in that time.

Not all of these workstations/users are accessing
the AFS server at once; peak usage is probably
around 100 simultaneous logins, average maybe
20-30 when the whole academic year is taken into
account.

Managing it is much nicer than NFS too. I only
wish we had the budget for a couple more servers
so I can do more with replication and transparent
server upgrades etc.

I'd *never* go back to NFS.