[OpenAFS] OpenAFS on MacOS X

[Derek Atkins]

"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

-- 
       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