[OpenAFS] OpenAFS on MacOS X

Derek Atkins warlord@MIT.EDU
10 Jul 2001 18:25:05 -0400

"Patrick J. LoPresti" <patl@curl.com> writes:

> This was my actual plan.  The basic structure of the AFS tree would
> consist of replicated RO volumes, with the individual users' home
> directories living on a server close to them.  This would work
> reasonably well even during outages, I think, except that someone
> using Windows or Mac could get stuck just browsing down to their own
> home directory.

Well, they would only hang when the network drops, and only for as
long as it takes to time out the unavailable fileserver(s).  Note that
they don't have a timeout per mountpoint, but rather a timeout per
fileserver.  And that timeout will only happen ONCE (per fileserver,
per outage) on a single client until the network comes back.

Note: perhaps the real solution here is to NOT have users "browse" to
they own homedir, but rather provide a pointer to it directly, either
via another drive or via a top-level shortcut.

> It would work all right if it were on a replicated volume and if
> stat() did not need to talk to the file server for the mountpoints.
> Ultimately, this really is almost exactly the same problem as the root
> volume has, but within a single cell.

Well, the problem per se is the same, except that root.afs is a KNOWN
volume whereas you want this for arbitrary volumes.  Currently there
is no way to signal to the client that any one volume is _special_.

> fine for some operations to require that connectivity, but it will
> occasionally be annoying if you need that connectivity just to browse
> around a bit.

Keep in mind that it will timeout, and then browsing will continue to
work.  One reason /afs is SO BAD is that there are multiple timeouts
PER ENTRY.  In your case I doubt there would be more than 10 entries
en mass; more likely a half-dozen servers per side of the network.  So
I think you are highly over-estimating the time it would take to
timeout (especially if you break down the users' mountpoints into
relatively small subdirectories).

> I suppose there are other tricks we could play, like dividing up the
> /users tree (among others) according to geographic location.

That would work, too.  You could have users/ma/cam/[a-z] and
users/ca/pao/[a-z], or something like that.  Then you wouldn't lose at
all because users/ma/cam/[a-z] can be replicated and you only "lose"
once you get to a particular subdirectory.

Another alternative is that you could provide a users/<username>
symlink into users/path/to/username.  That would also solve your
problem if you train people to always use the symlink path.

> That is unfortunate.  It would be nice if there were a networked file
> system that actually worried about things like the Mac Finder and the
> Windows Explorer.  It requires keeping the metadata for the top-level
> of a volume outside the volume; but that is not the way any of these
> systems work, probably because it is not very Unix-like.  "The
> permissions are in the root inode, of course; where else would they
> be?"

Well, consider that most Unix file browsers don't have this problem
(yes, there are exceptions) and that most non-Unix systems weren't
meant to be networked (at least until VERY recently).


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available