[OpenAFS] OpenAFS vs NFSv4?

[Dean Anderson]

> From: Derrick J Brashear <shadow@dementia.org>

> The ability to transparently fall over to one is in the client, though.
> An automount map and NFSv3 should have the same ability, I'd guess, but
> doesn't.

There was an NFS client implementation (in MIT Athena???--I don't remember
where/who but it didn't catch on commercially) that did this.  OSF/1
invented the spongy mount -- soft on directories, hard on files. This
works pretty good in conjunction with an automounter.  Some years ago I
wrote some programs that walked a file tree looking for DFS mounts in
advfs (files starting with %), then queried a DCE FLDB, and made an
automounter map that emulated the DCE namespace, for machines that didn't
run DFS. (wish I still had that code. It is owned by Borland now, and they
probably lost it after closing OEC in Boston)

> > The key to getting the idea to spread, is to create a clear and sharp
> > exposition of the benefits which highlights the distinctions with other
> > distributed file systems.  I don't think this message does the trick,
> > but hopefully it helps.
>
> The other thing is the maintenance burden that people talk about seems to
> be overstated. The buy-in cost is non-trivial, but I have an AFS cell
> which I've been running since 1994, with really no substantial work done
> on it in years. (And secretly the cell was cloned from another whose name
> I had no legitimate DNS claim on, which was about a year older)

Here, here. The OSF Research Institute afs cell ran with 9 fileservers and
hundreds of users (RI staff, plus others), under very heavy use for many
years.  When X/Open, The X Window Consortium, and OSF merged to form the
Open Group, the RI was severely downsized. I reduced the cell from 9
servers to 3 in about a few days. That included backups, and replacing all
the fileservers with different machines and disks---better machines had
been freed up, and I wanted to have those going forward.  Moving filesets
transparently is truly a wonderful thing.  Compare this with replacing an
NFS fileserver: repartioning, tapes, tars, re-IP-number...

OSF also used AFS as a way of supporting some offerings --- Full Support
customers were shipped AFS client software, and credentials to login to
the OSF syseng cell to get source code updates.

The "problem" with AFS is that system administration A to Z has to be just
about mastered before you get started, to set up a cell. Its not just a
simple add on. You have to install software, choose a name (learning about
global namespace and DNS), setup time syncronization, setup partitions,
volumes, install clients, create users, make filesets, etc.  This is
daunting.

By contrast, one gets a unix box (in the old days). Plays with it. Creates
some accounts. Then gets some workstations some time later. Creates
accounts on all, one by one. Then decides they want to use NFS. Later they
learn the benefits of single user database.  Later they learn about time
syncronization problems. Later they learn about automounters.  Small steps
seem much easier.  But each of these small steps come with constant
problems that are often lessons learned the hard way.  AFS does tend to
avoid those pitfalls at the expense of greater lead time getting started.

I once had a development file server (Sun e3500) destroyed by a new user
who didn't quite understand unix, nfs, and automounters. Root was
permissively given out (not my policy), and clients universally trusted.
So he does a find on the workstation root, and gets the server mounted on
his workstation. Somehow, he thinks he doesn't need all these extra files
on his workstation, so he starts removing them. The fileserver was half
wiped by the time someone stopped it. I was called in to fix the file
server...  I suppose this could happen with AFS, but I think its less
likely, and AFS doesn't respect root@client.

		--Dean