1 / 21

The Andrew File System (AFS)

The Andrew File System (AFS). Hanul Sung (husung@dcslab.snu.ac.kr) School of Computer Science and Engineering Seoul National University. Contents. Introduction of the AFS Basic tenets of the AFS Problems with the AFSv1 Solutions with the AFSv2 Cache Consistency

wards
Download Presentation

The Andrew File System (AFS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Andrew File System (AFS) Hanul Sung (husung@dcslab.snu.ac.kr) School of Computer Science and Engineering Seoul National University

  2. Contents Introduction of the AFS Basic tenets of the AFS Problems with the AFSv1 Solutions with the AFSv2 Cache Consistency Performance comparison: AFS vs. NFS Summary

  3. Introduction Of The AFS • The Andrew File System • Goal • Scalability for a distributed file system • A server supports as many clients as possible • Design and implementation • The protocol between clients and servers • Cache consistency

  4. The Andrew File System • Version change • Because AFSv1 didn’t scale as desired, AFSv2 is appeared • The basic tenets • Whole file caching on the local disk of the client from the server • open() : The entire file is fetched • read()/write() : Be redirected to the local file system • close() : The file is flushed back to the server • Benefits • Low network communication overhead and fast

  5. The AFSv1 Actions App open() read()/write() close() home TestAuth(/home/remzi/notes.txt) …. remzi …. Fetch(/home/remzi/notes.txt) Local memory ….notes.txt ……. ship(notes.txt) Local disk Store(/home/remzi/notes.txt) Server(Vice) Client(Venus) • Naming • Server : Vice • Client : Venus

  6. Problems With The AFSv1 The server CPU became the bottleneck of the system • Problems • Path-traversal costs are too high • The server must perform a full pathname traversal • The client issues too many TestAuth protocol messages • A large of traffic to check a local file was valid • Load is not balanced across server • The server used a single process per client • Context switching and other overheads are induced

  7. Solutions With The AFSv2 • The problem • Too many TestAuth() protocol messages • Added notion • A callback • To reduce the number of client/server interactions • The server will inform the client when a cached file has been modified • Server records who has copy of file • The results • The client don’t need to contact the server to find out whether the file has changed • Reducing the load on the server

  8. Solutions With The AFSv2 • The problem • Too much path-traversing costs • Added notion • A file identifier (FID) • Instead of pathnames • Volume number + File number + Uniquifier • The results • The server doesn’t need to traverse full pathnames • Reducing the load on the server

  9. Reading A File Of The AFSv2 App1 open(/home/remzi/notes.txt) read()/write() Fetch(homeFID, “remzi”) home callback App1 ship(remzi’s contents,FID) …. remzi …. callback App1 Local memory Fetch(remziFID, “notes.txt”) ….notes.txt ……. ship(notes’s contents,FID) Local disk Server(Vice) Client(Venus) • Client-side and file server actions • AFS behaves nearly to a local disk-based file system

  10. Cache Consistency Of The AFSv2 • Aspects • Update visibility • Cache staleness • Important cases • Between processes on different machines • Updates visible and invalidates cached copies when the updated file is closed • Between processes on the same machine • Writes are visible immediately • Cache consistency is easy to understand on AFSv2 • Because of callbacks and whole-file caching

  11. Cache Consistency Timeline P3 P2 P1 close() read() open(F) write(Orange) read() close() open(F) close() write(Yellow) open(F) close() write(Red) open(F) close() write(Green) open(F) open(F) open(F) read() close() close() read() Server(Vice) Client(Venus) Client(Venus) • A last writer wins • A last client updates the entire file on the server

  12. Crash Recovery rebooting Client1 Client3 TeshAuth callback Server Client2 Client4 • Case 1 • Client recovery

  13. Crash Recovery Client1 Client3 rebooting Server Don’t trust your cache contents! Client2 Client4 • Case 2 • Server recovery • Callbacks are keep in memory • When the server reboots, it doesn’t know which client has which files

  14. Crash Recovery Client1 Client3 rebooting Server Heart beat message Client2 Client4 • Case 2 • Server recovery • Callbacks are keep in memory • When the server reboots, it doesn’t know which client has which files

  15. Scale And Performance Of AFSv2 • Scalability • Each server could support about 50 clients • Performance • Client-side performance comes quite close to local performance • Comparison: AFS vs. NFS • Typical read/write patterns analytically for files of different sizes • Small files have Ns blocks, medium files have Nm blocks, large files have Nl blocks • Small files and medium files fit into the memory of a client, large files fit on a local disk • Lnet is access time to the remote server, Ldisk is to local disk, Lmem is to local memory • Assumption : Lnet >Ldisk >Lmem

  16. Scale And Performance Of AFSv2 • AFS vs. NFS • Case 1 • First access to a file • Performance comparison • NFS = AFS • Local file system caching • The time to fetch the file from the server dominates

  17. Scale And Performance Of AFSv2 • AFS vs. NFS • Case 2 • A large-file sequential re-read • Performance comparison • NFS < AFS • AFS has a large-file in local disk • NFS have to re-fetch the large-file in local memory from the remote server

  18. Scale And Performance Of AFSv2 • AFS vs. NFS • Case 3 • Sequential writes of new files • Performance comparison • NFS = AFS • AFS writes the file to the local cached copy and then sends the file to the server • NFS writes the buffers to the local memory, sends the blocks to the server

  19. Scale And Performance Of AFSv2 • AFS vs. NFS • Case 4 • A sequential file overwrite • Performance comparison • NFS < AFS • In AFS, the client first fetches the old file before over-writing • In NFS, the client overwrite blocks and avoid the initial read

  20. Scale And Performance Of AFSv2 • AFS vs. NFS • Case 5 • Access a small subset of data within large files • Performance comparison • NFS > AFS • AFS protocol fetches the entire file, but NFS, as a block-based protocol • In case of single over-write, doubling the performance impact

  21. Summary • The Andrew file system : a distributed file system • The protocol between servers and clients • Minimizing server interactions through whole-file caching and callbacks • A local disk-based file system nearly • The cache consistency • Simple to understand • Compare the AFS with the NFS • The AFS has a local disk, but NFS has only a local memory • The AFS uses call backs, but NFS forces clients to check with the server periodically • In AFS cache consistency is simple, but in NFS that is complicated • The AFS is a file-based protocol, but the NFS is a block-based protocol

More Related