Andrew File System

1
Andrew File System

• Group 9
• Aslahiah Hussain (GS13386)
• Zoraidah Ahmad (GS13390)
• Azlina Mohd Mydin (GS14097)
• Lee Kah Min (GS14176)
• Rosita Mohamed Othman (GS14479)

2
Contents

• Introduction
• AFS Design
• Implementation
• Cache Consistency Mechanisms
• Other Aspects
• Related Research
• Conclusion

3
Introduction

• Andrew File System (AFS) is one of the
  distributed file systems that been developed at
  Carnegie Mellon University (CMU) for use as a
  campus computing the information system.
• The design of AFS reflects an intention to
  support information sharing on a large scale by
  minimizing client-server communication.
• It is designed to be heterogeneous, scalable,
  it runs efficiently on variations on UNIX.
• Main Goal
• AFS provide scalability to thousands of
  workstation at one site while offering users,
  applications administrations the conveniences
  of a shared file system.

4
AFS Design

• 2 design characteristics-
• Whole-file serving
• Whole-file caching

5
Whole-file serving
AFS Design (cont.)

• the entire contents of directories and files
  are transmitted to client computers by AFS server
  

6
Whole-file caching
AFS Design (cont.)

• once a copy of a file or a chunk has been
  transferred to a client computer it is stored in
  a cache on the local disk. The cache contains
  several hundreds of the files most recently used
  on that computer. The cache is permanent,
  surviving reboots of the client computer. Local
  copies of files are used to satisfy clients open
  requests in preference to remote copies whenever
  possible.

7
Implementation

• AFS is implemented as two software components
  that exist as UNIX processes called Vice and
  Venus.
• Vice - name given to the server software that
  runs as a user-level UNIX process in each server
  computer
• Venus - user-level process that runs in each
  client computer and corresponds to the client
  module.

8
Distribution of processes in the AFS
9
Implementation (cont.)

• The files available to user processes running on
  workstations are either local or shared.
• Local files are handled as normal UNIX files,
  stored on a workstations disk and are available
  only to local user processes.
• Shared files are stored on servers, and copies
  of them are cached on the local disks of
  workstations

10
Implementation (cont.)

• The UNIX kernel in each workstation and server is
  modified version of BSD UNIX.
• The modifications are designed to intercept open,
  close and some other file system calls when they
  refer to files in the shared name space and pass
  them to the Venus process in the client computer.
  
• Venus manages the cache, removing the least
  recently used files when a new file is acquired
  from a server to make the required space if the
  partition is full.

11
Implementation (cont.)

• The workstation cache is usually large enough to
  accommodate several hundreds average-sized files,
  rendering the workstation largely independent of
  the Vice servers once a working set of the
  current users files and frequently used system
  files has been cached.

12
System call interception in AFS
13
Implementation (cont.)

• User programs use conventional UNIX pathnames to
  refer to files, but AFS uses file identifier
  (fids) in the communication between the Venus and
  Vice processes.
• The Vice servers accept requests only in terms of
  fids.
• Venus translates the pathnames supplied by
  clients into fids using a step-by-step lookup to
  obtain the information from the file directories
  held in Vice servers.

14
Net
User process
UNIX kernel
Venus
Vice
open(FileName,
If
FileName
refers to a
mode)
file in shared file space,
Check list of files in
pass the request to
local cache. If not
Venus.
present or there is no
valid
callback promise
send a request for the
file to the Vice server
that is custodian of the
Transfer a copy of the
volume containing the
file.
file and a
callback
promise
to the
Place the copy of the
workstation. Log the
Open the local file and
file in the local file
callback promise.
return the file
system, enter its local
name in the local cache
descriptor to the
application.
list and return the local
name to UNIX.
read(FileDescriptor,
Perform a normal
Buffer, length)
UNIX read operation
on the local copy.
write(FileDescriptor,
Perform a normal
Buffer, length)
UNIX write operation
on the local copy.
close(FileDescriptor)
Close the local copy
Replace the file
If the local copy has
and notify Venus that
contents and send a
been changed, send a
the file has been closed.
callback
to all other
copy to the Vice server
clients holding
c
a
l
l
b
a
c
k
that is the custodian of
promises
on the file.
the file.
Implementation of file system calls in AFS
15
Cache Consistency Mechanisms

• Files and directories are cached on the local
  disks of clients using consistency mechanism
  based on callbacks.
• When Vice supplies a copy of a file to a Venus
  process, it is also provides a callback promise
  which is a token issued by Vice server.
• The callback promises are stored with the cached
  files on the workstation disks and have two
  states valid and cancelled.

16
Cache Consistency Mechanisms (cont.)

• If the value is cancelled ----- then a fresh
  copy of the file must be fetched from the Vice
  server, but
• if the token is valid ----- then the
  cached copy can be opened and used without
  reference to Vice.
• For each file with a valid token, Venus must send
  a cache validation request containing the file
  modification timestamp to the server.
• Since the majority of files are not accessed
  concurrently and over write in most applications,
  the callback mechanisms results in a dramatic
  reduction in the number of client-server
  interaction.

17
Management Issues
Bulk Transfers
UNIX Kernel modifications
Economy
Reliability
OTHER ASPECTS OF AFS
Security
Availability
Threads
Location Database
Read-only replicas
Partial File Caching
Wide-area Support
Performance
18

• Management Issues
•  
• AFS has the ability to move volumes between file
  servers for load-balancing purposes. It also has
  the ability to dump a snapshot of a volume to
  tape. Dump volume functionality is to support
  three modes of operation. These include-
• dumping the entire volume
• dumping only the parts of a volume that reside on
  the local disk residency, and
• only dumping the volume header files.

19

• Security
•  
• AFS uses Kerberos authentication to enforce
  security without inhibiting legitimate uses of
  the system .

20

• Performance
• Whole-file caching and the callback protocol led
  to dramatically reduced loads on the server.

21

•  Availability
• AFS is available for most Berkeley-derived UNIX
  variants including Ultrix, SunOS, AIX, and HP/UX.

22

• Reliability
• AFS supports a limited multiple residency for
  unchanging files. As servers go down, only
  non-replicated portions of the AFS filespace
  become inaccessible, leaving the rest of the file
  system intact. Replicated data is automatically
  fetched from one of the remaining servers. The
  clients automatically balance requests between
  all the servers containing a particular file.

23

• Bulk Transfers
• AFS transfers files between clients and servers
  in 64-kilobyte chunks. The use of such a large
  packet size is an important aid to performance,
  minimizing the effect of network latency. Thus
  the design of AFS enables the use of the network
  to be optimized.

24

• Economy
•  
• As with NFS, AFS servers can run on inexpensive
  workstations using commodity priced disks.

25

• Extra Features
• AFS supports several useful abstractions absent
  in typical UNIX file systems, including access
  control lists and guaranteed quotas.

26

• UNIX Kernel Modifications
• The UNIX kernel in AFS hosts is altered so that
  Vice can perform file operations in terms of file
  handles instead of the conventional UNIX file
  descriptors.

27

• Location database
• Every server contains a copy of a fully
  replicated location database giving a mapping of
  volume name to servers. Temporary inaccuracies in
  this database may occur when a volume is moved,
  but they are harmless because forwarding
  information is left behind in the server from
  which the volume is moved.

28

• Threads 
• The implementation of Vice and Venus make use of
  a non-pre-emptive threads package to enable
  requests to be processed concurrently at both the
  client (where several user processes may have
  file access requests in progress concurrently)
  and at the server.

29

• Read-only replicas
• Volumes containing files that are frequently
  read but rarely modified such as the UNIX /bin
  and /usr/bin directories of system commands and
  /man directory of manual pages, can be replicated
  as read-only volumes at several servers.

30

• Partial File Caching
• Version 3 of AFS allowing file data to be
  transferred and cached in 64-kbyte blocks while
  still retaining the consistency semantics and
  other features of the AFS protocol.

31

• Wide-area support
• Version 3 of AFS supports multiple
  administrative cells, each with its own servers,
  clients, system administrators and users. Each
  cell is completely autonomous environment, but a
  federation of cells can cooperate in presenting
  users with a uniform, seamless file name space.

32
Related Research

• Spasojevic, M., Satyanarayanan, M. An Empirical
  Study of a Wide-Area Distributed File System.
  Technical Report. Transarc Corporation. Nov 1994.
• This paper performs a performance study of a
  running distributed file system which is on the
  Andrew File System (AFS).

33
Related Research (cont.)

• The goal Conducting an empirical study to
  understand how effective various AFS mechanisms
  were in a large-scale, wide-area context. It
  presented evaluations concerning the AFS data
  profile, the performance and reliability, and the
  sharing outline.
• As demonstrated by the experiments, AFS can deal
  with large distributed file systems. Comparing
  with the data sharing mechanisms on the Internet
  (e.g. Archie, Gopher, WWW), AFS address many
  issues not addressed by that systems caching,
  replication, location transparency,
  authentication and protection mechanisms. This
  would allow the utilization of such system as the
  basis for building a more scalable service on the
  Internet domain.

34
Related Research (cont.)

• Satyanarayanan, M., Spasojevic, M. AFS and the
  Web Competitors or Collaborators? Proceedings of
  the Seventh ACM SIGOPS European Workshop. Sept
  1996, Connemara, Ireland.
• This paper shows that Web and AFS are not really
  competing technologies. Rather, they represent
  complimentary technologies that may be used
  together for mutual advantage.

35
Conclusion

• AFS demonstrated the feasibility of relatively
  simple architecture using serve state to reduce
  the cost of maintaining coherent client caches.
• AFS outperforms in several situations compare to
  other distributed file systems.