On Tuesday, October 10, 2006 01:16:52 AM -0400 Marcus Watts <[EMAIL PROTECTED]>
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) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
