[OpenAFS] AFS on BSD 'nix ? (yaioa)

[Marcus Watts]

Paul Blackburn <mpb@est.ibm.com> writes:
> I just did a google search for "-dynroot afsd" and
> found the "OpenBSD man page for afsd" [0] which seems
> to have different command line arguments than either
> Transarc AFS or OpenAFS.
> 
> Yet another implementation of AFS?
> 
> Counting RedHat's own implementation this makes 4
> (unless there are more?).
> 
> It's good to see there is so much interest in AFS
> but would it not be more sensible to be compatible
> with Transarc and OpenAFS?

OpenBSD comes with arla.
	http://www.stacken.kth.se/project/arla
The reason why is licensing issues - arla comes with a BSD license,
OpenAFS comes with IPL--an opaque legal document similar to GPL except
with even weirder patent language.

I don't know how you're counting things, but
	transarc afs -> openafs -> redhat
basically, openafs work done on top of transarc, while redhat is (I
believe) merely repackaging it and not making big changes of their
own.  So you are at best looking at 3 different snapshots of the same
basic code base (there is of course still considerable room for
mutation), and in practice, you could almost consider it the same thing
with different build options.

arla has a completely different code base, so it's *much* more
different than you think.  The arla folks are trying to be as
compatible as possible w/ afs at the "user" level, but not necessarily
at the API level.  They're also trying some different approaches: the
kernel code is much smaller, and there's a big userland process that
does the actual work.  Probably not as good performance, but less
potential for runaway scary bugs.  They're apparently still cacheing
the whole file, so I don't know how well arla would cope with really
big files.  From a programmer/API standpoint, there are obviously big
differences.  One is that they (obviously) use kth kerberos.

The Arla folks aren't done yet, and one of the big missing pieces is
complete support for the DB and file server back end pieces.  But if
that were your interest, you probably wouldn't want openbsd anyways -
you want to be able to maintain multiple disk reads going at once while
servicing network calls, which means you want kernel threads w/
userland support, which openbsd doesn't yet have (the closest it comes
is a system call "rfork" which has interesting semantics.)

I suppose in a sense you could consider arla to be the "linux"
of the AFS world, with an interesting twist on the licensing.

				-Marcus Watts
				UM ITCS Umich Systems Group