[OpenAFS-devel] Fileserver as Masters Thesis

[Jeffrey Hutzelman]

On Monday, September 19, 2005 06:31:54 PM +0200 Frank Bagehorn 
<FBA@zurich.ibm.com> wrote:

> - Or you create a virtual layer for the existing fileservers, so that you
> would have a well-defined interface to whatever lies below. (NAMEI or
> INODE or DB or whatever comes to peoples mind.)

Actually, we already have that layer.  OpenAFS doesn't have two 
fileservers; it has one fileserver which can be compiled with any of three 
different backends (inode, namei, and windows).  I'd expect work in this 
area to involve writing new fileserver backends, not whole new fileservers.

That said, I've done a couple of things along the export-local-files line 
that did use completely independent code.  One was hostafs 
(/afs/cs.cmu.edu/project/systems-jhutz/hostafs), which does an NFS-like 
export of part or all of the server's local filesystem.  It models each 
server as an independent cell, with each exported filesystem as an 
independent volume; the hostafs server provides both VLDB and fileserver 
services.  It has a variety of limitations, including the fact that write 
support was never implemented, and there is indeed no volserver.

I also have a much simpler tool, tafssrv 
(/afs/cs.cmu.edu/project/systems-jhutz/tafssrv), which exports one or more 
volumes whose contents are defined by a configuration file processed at 
startup.  It can be used as part of an existing cell or standalone, 
providing its own VLDB service.  And, it provides some support for 
volserver operations; you can even do dumps of its virtual volumes -- one 
of the applications was to export a volume containing a copy of the PTS 
database, so we could back it up along with the rest of the cell.  Again, 
tafssrv is read-only.  It also has very limited access-control -- by 
default, users in the UserList get rlk access to all files, and other 
clients get rlk access only to files with the global read or execute bits 
set.  This can be modified in either direction -- you can grant rlk on all 
files to all clients (noauth mode), or you can prevent non-privileged 
clients from accessing anything at all (restricted mode).

These tools are interesting, but they're not the basis for a full-service 
fileserver.  The real fileserver does a lot of things related to 
authentication, client tracking, callbacks, ACL's, and so on, which are not 
dependent on the backend being used.  Work like what was proposed at the 
start of this thread should almost certainly done by providing new 
fileserver backends.


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