Operating Systems
Linux UNIX
IBM AIX UNIX
IBM OS2
  MicroSoft WindowsNT
GU Interfaces
XWindows System
MicroSoft Windows95
MicroSoft Windows98
File Systems and Services
AFS (Andrew File System)
IBM DCE/DFS
SAMBA
Information
Howtos/Faqs/Infos/Tips
What is ...
Services
Google Search!
What is that Site Running?
 Want to get Linux?
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


     


    The contents of this website are Copyleft 1998 by Baypoint Systems.
    Website questions? Email the WebMaster [email protected]
     

    @Home Networkgraphica by Gimp