[OpenAFS] Migration and slow AFS performance

[Dan Mezhiborsky]

On Sat, 2021-05-29 at 23:16 -0400, Jeffrey E Altman wrote:
> If you are willing to explain, I'm sure the community would
> appreciate 
> hearing the reasons behind the migration away from OpenAFS and how
> the 
> replacement was selected.

Sorry for the very late reply, and thank you for offering to help. I'll
do my best to ourline our reasons for the migration away below (note
that we're still using OpenAFS today):

We (Cooper Union microLab) are a small student team that manages the
computing resources for our school's EE department. Our core work
resolves around making machines with various tools available to the
other students. We use OpenAFS for home directories, public/shared
directories, and shared software, and have been doing so for a long
time.

OpenAFS meets our needs well. However, development of OpenAFS has
declined significantly, and, in truth, there is a significant fear that
if we don't switch to anything more modern, we could eventually end up
with an unmaintained project that virtually everything else we do
relies on.

Unfortunately, at this time and to my knowledge, there really isn't an
open-source replacement for OpenAFS - no other OSS file system appears
to be so specifically useful for the university computing evironment.
Switching is something we feel we need to do out of necessity, not for
want of features that OpenAFS doesn't have.

I would note that it's a sign of just how good AFS is for these
applications that it seems to be so difficult to switch to anything
else. This is a relatively small college, and we don't absolutely need
the file system to be distributed, so that opens up a range of options
for us. We intended to switch to either kerberized NFS or CIFS.

I don't think those can really be considered replacements for AFS, but
they will likely be good enough for us. I wish this was not the path we
had to go down.

Thank you very much to the maintainers for the work you have done and
continue to do for the OpenAFS community.

Thanks and I would be glad to hear any other thoughts on this.
Dan Mezhiborsky
Cooper uLab