[OpenAFS-port-darwin] AFS as OS X home directory

[Phil.Moore@morganstanley.com]

>>>>> "Steve" == Steve Lidie <sol0@Lehigh.EDU> writes:

Steve> Apologies is this is off-topic. I have AFS running on OS X
Steve> 10.2.2, with MIT krb authentication to our AFS servers and
Steve> directory access to our LDAP server for user home directory
Steve> information.  This works great, and any AFS user can login in a
Steve> manner identical to our AIX and IRIX workstations.  I have 2
Steve> problems, one is a show-stopper.

Steve> Any OS X file dialog wants to show a directory tree of all
Steve> mounted volumes, so showing our AFS home space with 10K+ users
Steve> takes several minutes.  Is there a way to customize OS X to not
Steve> do this, or perhaps start the display at the current working
Steve> directory?

If you have a directory with 10K+ AFS volume mount points, then the
MacOS Finder isn't the only application that going to suffer from
performance problems when you attempt to list this directory.

This isn't a new problem in the world of distributed filesystems,
either.  Traditionally, the UFS filesystem directory hashing algorithm
always performed *very* poorly for large number of directpry entries,
and this is why large enterprises have typically hashed the user
namespace in some way to add directory structure, and keep the number
of entries in a single directory to a minumum.

Here at Morgan Stanley, we have as many as 30,000 potential users, and
a single directory just wouldn't scale.  In our AFS namespace, we
chose to hash the names on the first initial, so my home directory is
in:

    /ms/user/w/wpm

But even that has proven to be a bit too much, as some of the single
letter directory have several 1000 entries, and they still can be slow
to list.   In the future, I want to change the namespace to hash on
the first *two* chars as follows:

    /ms/user/w/wp/wpm

This is less ashetically pleasing, but too bad -- it scales better,
and its deterministic (and I know I'll get my way :-P)

But, there's another bit of administrative cleverness that might help
you.  If you really want to preserve the flat *directory* namespace
for users, then you can easily do so, and still hash things in the
scalable fashion I suggest above (and I would recommend to go straight
to a 2-level hash, as my second example shows).

Create your actual user mount points on:

    /afs/mycell/user/n/na/name

but give them a convenience symlink:

    /afs/mycell/user/name -> n/na/name

Do NOT use another mount point, or you'll still have the Finder Column
View and the Aqua File Diagog's wedging on a directory full of mount
points.  If that directory is full of symlinks, then you'll see a
folder full of "aliases" (not technically the same as a MacOS alias,
but they look the same in the Finder and the Dialog box), and the
listing will be very fast.

Listing a directory/folder such as /afs/mycell/user/n/na will still be
a tad slow, since you'll have a lot of mount points in those single
directories, but you'll have a far more manageable number, and the
interactive response time should be acceptable to your users.  

Phil Moore
Member, OpenAFS Advisory Board