The Andrew file system (AFS) is a distributed networked file system developed by Carnegie Mellon University as part of the Andrew Project. It is named for Andrew Carnegie and Andrew Mellon. Its primary use is in distributed computing.

AFS has several benefits over traditional networked file systems, particularly in the areas of security and scalability. It is not uncommon for enterprise AFS cells to exceed 50,000 clients. AFS uses Kerberos for authentication, and implements access control lists on directories for users and groups. AFS's client-level caching improves filesystem perfomance, and allows limited filesystem access in the event of a server crash or a network outage:

is a location-independent file system that uses a local cache to reduce the workload and increase the performance of a distributed computing environment. A first request for data to a server from a workstation is satisfied by the server and placed in a local cache. A second request for the same data is satisfied from the local cache. (Source - searchStorage.com)

AFS files are cached on demand on the local workstations. Read and write operations on an open file are directed only to the cached copy. When a modified file is closed, the changed portions are copied back to the file server. Cache consistency is maintained by a mechanism called callback. When a file is cached the server makes a note of this and promises to inform the client if the file is updated by someone else. Callbacks are discarded and must be re-established after any client, server, or network failure, including a time-out. Re-establishing a callback involves a status check and does not require re-reading the file itself.

A consequence of the whole file locking strategy is that AFS does not support large shared databases or record updating within files shared between client systems. This was a deliberate design decision based on the perceived needs of the university computing environment. It leads, for example, to the use of a single file per message in the original email system for the Andrew Project, the Andrew Message System, rather than the more customary single file per mailbox.

A significant feature of AFS is the volume, a tree of files and sub-directories. Volumes are created by administrators and linked at a specific named path in an AFS cell. Once created, users of the filesystem may create directories and files as usual without concern for the physical location of the volume. A volume may have a quota assigned to it in order to limit the amount of space consumed. As needed, AFS administrators can move that volume to another server and disk location without the need to notify users; indeed the operation can occur while files in that volume are being used.

AFS volumes can be replicated to read-only cloned copies. When accessing files in a read-only volume, a client system will retrieve data from a particular read-only copy. If at some point that copy becomes unavailable, the client will look for any of the remaining copies. Again, users of that data are unaware of the location of the read-only copy; administrators can create and relocate such copies as needed. The AFS command suite guarantees that all read-only volumes contain exact copies of the original read-write volume at the time the read-only copy was created.

The file name space on an Andrew workstation is partitioned into a shared and local name space. The shared name space is identical on all workstations. The local name space is unique to each workstation. It only contains temporary files needed for workstation initialization and symbolic links to files in the shared name space.

This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Andrew File System".

Preface: The following information is provided with explicit permission from the University of Michigan, College of Engineering, Computer Aided Engineering Network (CAEN). This information is reprinted for educational purposes only and does not constitute an endorsement of Teradactyl or its products and services by this institution.

Introduction to the Andrew File System (AFS)

All of CAEN’s workstations use AFS, which is derived from the Andrew File System, developed at Carnegie-Mellon University. AFS allows many machines to share files over a network, and provides a simple, integrated working environment.

The AFS file system comprises file servers and clients. A file server stores files that other computers, called clients, need to access. AFS clients can access standard network file servers in addition to the new AFS file system, providing better performance with minimum inconvenience. In general, the task of a distributed file system is to make a shared file system accessible to hosts via a network. The file system must control which individual hosts and users have rights to mount file systems and to access files. AFS defines a protocol for making file systems available to other machines. This protocol determines automatically where the client can find a desired file.

A number of server machines export the AFS file system over the network to any number of client machines. Each client machine has a cache manager which requests files from the servers, stores them in a cache on the local hard disk and returns them when they have been updated. The cache manager is an active client; that is, it controls the transfer of files to and from the server, and locates alternate copies of files if a server should fail. Retrieving and updating files only when necessary minimizes network use and delay. Not only does this make file access faster, it also increases the number of machines that can access a single server without a decline in performance.

Kerberos

AFS uses MIT’s Kerberos authentication scheme to validate users’ rights to access files, and it improves network security significantly. By default, an ordinary user has very limited access rights. When you wish to access files, the AFS client connects to the server through a mutual authentication process. This authentication not only ensures the client has valid access to the server volumes, but that the server is a valid file server for the client. In order to access files in the AFS file space, you must provide an AFS password to receive authentication. When you enter your Kerberos password, it is encrypted before sent to the server, which must be able to interpret and verify it. AFS establishes your access rights after authentication by granting you tokens. AFS uses Kerberos to perform the necessary authentication, and then examines your token to determine your rights to each file. Files are only exchanged between a client and a server if both machines are able to recognize the token as valid.

AFS allows you to access all AFS files around the world through a single entry point in the file system. The /afs tree contains several AFS cells. These cells are distinct administrative domains that may comprise many different servers and volumes fused together under a single directory tree. For example, the CAEN AFS cell is engin.umich.edu; and the ITCS cell is umich.edu.

In addition to the local cell, many foreign cells from other AFS domains are accessible, whether they are located across campus or across the country. This allows you to access files across the nation as easily as a local disk on any workstation.

File Permissions

AFS allows seven distinct directory access rights that may be granted to specific users and user-definable groups. Though CAEN still supports standard UNIX file permissions, they are used in conjunction with AFS access rights only minimally. An authorized user can add each specific access right to, or delete it from, any user or group. The following commands describe the allowable AFS file permissions.

read (r)

Allows you to open files within a directory for read access only and to copy the contents of any file in the directory.

lookup (l)

Allows you to list the names of the files in the directory; without this right, you may access files only if you know their names beforehand.

delete (d)

Allows you to delete files from the directory.

write (w)

Allows you to append to, modify, and overwrite existing files in the directory; does not allow you to create new files.

insert (i)

Permits you to create new files in a directory.

lock (k)

Allows you to lock files for exclusive use.

administer (a)

Allows you to change access rights on the directory.

AFS predefines three standard user groups for convenience. The system:administrators group contains all of the local AFS administrators; the system:authuser group consists of all users who have an authenticated, local AFS account; the system:anyuser group includes all those who have access to AFS. Since AFS is used across the entire country, this is a very broad implementation of the UNIX world rights.

Preface: The following information is provided with explicit permission from USENIX: The Advanced Computing Systems Association. This information is reprinted for educational purposes only and does not constitute an endorsement of Teradactyl or its products and services by USENIX or the OpenAFS community. Teradactyl cannot accept donations to this fund directly and does not receive any portion of the donated proceeds. This information and the associated links are provided as a free service to the OpenAFS community and USENIX.

The OpenAFS Fund

USENIX announces the formation of the OpenAFS Fund, a financial means of supporting The OpenAFS Project.

OpenAFS is a free, secure, scalable, distributed file system used by large corporations and small companies alike. Originally created as a research project by IBM and Carnegie Mellon University in the early 1980s, then becoming a licensed product of IBM/Transarc Labs, the software was open sourced by IBM in October 2000 and has seen much growth and development since then.

Why Donate to OpenAFS?

The OpenAFS project suffers from the classic Open Source problem: more requests than people can find time to work on. Few contributors to OpenAFS are currently paid for their time, and those who are, are funded by their employers (to whom OpenAFS is eternally grateful). Frequently contributors' work is driven by critical bugs and site-specific problems. Work on new development, non-critical bugs, code audits, performance enhancements, and documentation is accomplished volunteers in their spare time.

Financial support of OpenAFS will enable the project to hire:

Developers for frequently requested features such as confidential communication, disconnected operations, long volume names, enhancements for Microsoft Windows, optimization for laptops, better administration software, and other items

Technical writers to create, update, and otherwise maintain documentation

Product managers to manage code contributions, perform code audits, plan long-term road maps, and provide support to the OpenAFS community

Financial support can also be used to purchase equipment and services necessary for carrying out the OpenAFS.org mission, which includes software subscriptions, licensing fees, certifications, and operating systems, among others.

Contributions will be allocated to projects under the direction of the OpenAFS Elders, the advisory board that guides the future development of OpenAFS.

How Do I Donate to OpenAFS?

USENIX is accepting donations on behalf of The OpenAFS Project through the OpenAFS Fund. Donations can be made by sending a check, drawn on a U.S. bank, made out to the USENIX Association, to:

OpenAFS Fund
USENIX Association
2560 Ninth St., Suite 215
Berkeley, CA 94710

or by making a donation online.

Your contribution may be tax-deductible as allowed by law under IRS Code Section 501(c)(3). Check with your tax advisor to determine whether your contribution is fully or partially tax-deductible.

If you wish to connect to the OpenAFS Fund page at USENIX you may click here.

Teradactyl will not accept donations to this fund directly and does not receive any portion of the donated proceeds. This information and the associated links are provided as a free service to the OpenAFS community and USENIX. Teradactyl is a corporate USENIX member.

Preface: The following information is provided under the terms of use established by the non-profit foundation Gentoo Foundation, Inc. "Gentoo" is a trademark of Gentoo Foundation, Inc. Teradactyl and our products and services are not part of the Gentoo project and are not directed or managed by Gentoo Foundation, Inc. This information is reprinted for educational purposes only and does not constitute an endorsement of Teradactyl or its products and services by this institution.

Gentoo Linux OpenAFS Guide - This guide shows you how to install an OpenAFS server and client on Gentoo Linux. This content is recommended for users with at least a basic understanding of OpenAFS. The contents of the document are licensed under the Creative Commons - Attribution / Share Alike license.

Interested in OpenAFS and want to build support for deployment in your organization? Check out the OpenAFS Success Stories!

OpenAFS is FREE to everyone worldwide! Visit the OpenAFS website!

Preface: The following paper was written by Teradactyl LLC. and presented at the AFS & Kerberos Best Practices Workshop 2005. It may be printed and/or redistributed for educational purposes only.

AFS Backup & Recovery Best Practices 2005: The purpose of this paper is to examine the general behavior of backup systems in relation to working with the Andrew File System (AFS). It is written as a guide for system administrators to help make them aware of all of the considerations for backup, restore, and disaster recovery that they need to take into account when putting together a backup and recovery strategy for AFS. The paper includes discussions on the features and limitations of the native backup and recovery programs provided with AFS. It is hoped that the information presented here can help administrators consider tradeoffs in cost, performance, and reliability for different types of solutions.