Table
of Contents
An Overview
The AFS global name space
Authentication and access
control
AFS Disk Cache
Special Note
AFS Frequently Asked Questions
An Overview
AFS is
an acronym for the Andrew File System, developed at Carnegie-Mellon University,
Pittsburgh, under a sponsorship from IBM. Today AFS is marketed
by Transarc Corporation and has been chosen by the Open Software Foundation
as the basis of it's Distributed File System DFS.
AFS is a network-distributed file system comparable
to Sun's NFS. AFS distinguishes between client machines and server machines.
An AFS client enables users to access data residing on AFS servers transparently
as if they were stored on a local disk. AFS servers in turn provide disk
storage for files and directories.
The
AFS global name space
Files and directories stored in the AFS file
system are stored in logical entities called volumes. A volume physically
resides in parts of a file server machine's physical storage (i.e.disks)
called partitions. The information about which volume is located
where and on which file server is managed by volume location server processes
running on servers inside the AFS cell.
The mapping information of files/directories to
volumes (i.e. mount points as in NFS terminology) is contained in
the file system itself and therefore the same for any client traversing
the AFS file space. Through adequate construction of mount
points it is possible to reference each file in AFS by a path name which
will be the same for every AFS client machine in the world.
In order to keep path names unique, an early component
of the path name is the cell name. An AFS cell is a collection of AFS servers
and clients. The cell is an administratively independant domain, and among
others the boundary for the validity of AFS userids.
Access to AFS files is location transparent. System
processes resolve each file's physical location automatically based
on information contained within the file system. The user does normally
not even know how many servers are in a cell. Files can sometime exist
in multiple copies on several servers for load balancing and availability
purposes, with the AFS cache manager choosing a copy based on
availability and topological distance in the network.
Authentication
and access control
The NFS file system uses the relatively weak
method of Unix uids and gids in order to control access to files shared
across the network, a method which works efficiently only in controlled
and closed environments.
AFS uses Access Control Lists stored with each
directory, which allow significantly finer specifications gif of access
rights.
Users are identified to AFS using Kerberos authentication.
AFS user identifications are global to the whole cell, and not necessarily
related to the local authentication on the user's workstation. Authenticated
users hold Kerberos tickets for the service 'afs', in AFS called a token.
Simply presenting a valid token is already proof
of authenticity. In order to limit the damage in case of accidental
disclosure tickets are therefore protected by an expiry date - after that
date the ticket or token is no longer accepted. The usual lifetime for
AFS is 25 hours, which forces the user to re-authenticate every day.
Based on the user's authentication, connections
to AFS file servers are automatically established when needed, using complex
Kerberos mutual authentication. Although data is exchanged in clear, control
information between a user's workstation and a fileserver is encrypted
using a key shared only between the workstation and the fileserver, making
it virtually impossible for another node on the network to
masquerade as the user, or to insert himself into an ongoing connection
and act on behalf of the user.
AFS
Disk Cache
AFS uses a part of the workstation's local disk
space as a cache for data transferred from an AFS file server. Files are
initially transferred using big chunks (of typically 64 kilobytes). Whenever
a user references parts of a file which are already in the cache, no network
transfer is required, making access to the file as performant as accessing
a file on the local disk. A callback mechanism between the client and the
server ensures integrity of the cache, i.e. that the copy of the file (or
its parts) in the cache is as recent as the copy on the server.
Special Note
In certain cases however AFS is not suited and
should not be relied on heavily. These cases include mission critical
applications which must not be affected in case of network problems. AFS
as a network file system relies (although not entirely) on a stable
network. Alas the complexity of networking is such that despite ongoing
improvements the possibility of a 'glitch' in network connectivity can
hardly be excluded. AFS is not suited in cases where the possible damage
caused by such a 'glitch' outweighs the advantages of using AFS; environments
that include many systems for which AFS is not available, e.g. Lynx OS,
OS/9 or HP-UX 9 clustering. While it is possible to mount /afs on a non-AFS
machine using NFS and a suitable AFS-Gateway and therefore to improve interoperability,
such a setup is more difficult to use and (as experience shows) not suited
for 'heavy' traffic.
AFS Frequently
Asked Questions
Ohio
State University: AFS distributed filesystem FAQ
Transarc.com:
AFS-Frequently Asked Questions
|