On Monday, September 19, 2005 06:31:54 PM +0200 Frank Bagehorn <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
