[OpenAFS] Re: why afs backup is so poorly supported

[Jeffrey Hutzelman]

On Tuesday, October 10, 2006 01:16:52 AM -0400 Marcus Watts <mdw@umich.edu> 
wrote:

> Obfuscation might still have been seen as helpful when
> explaining to bean-counter type people why the fileserver shouldn't
> also be the mail server

I'm pretty sure the people designing AFS didn't have that problem. :-)
In fact, the fileserver _was_ the mail server -- the Andrew Message System 
stored all messages in AFS, at every stage of processing.  Mail clients 
read messages directly out of the user's mailbox in AFS.


> However, the lack of any reasonable
> way to manage AFS identities, mount points, and acls in the filesystem
> was surely the over-riding concern.

That, and the need for the fileserver to efficiently do its job.  The AFS 
protocol is based on file identifiers (volume, vnode, uniqifier), not paths 
and filenames, and the fileserver's data is organized in a way that makes 
it efficient to find a file's contents based on its FID.  In the 
traditional fileserver, that meant the vnode index contained the inode 
number of each underlying file, and the kernel was modified to provide 
system calls to access files by inode number.  The namei fileserver 
accesses files by name, but using names which are computed from the file's 
FID, because that's what the server knows when it needs to access a file.

I will note that the NFS protocol is rather similar, and pretty much all 
NFS servers require help from the kernel to obtain "handles" identifying 
files, which can be given to clients and then later used to find the same 
file again.  These generally consist of a filesystem ID, inode number, and 
a "generation number", which performs the same function as AFS's vnode 
uniqifier.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA