NFS, AFS, Sprite FS: Difference between revisions
No edit summary |
Started posting notes on NFS/AFS/SpriteFS |
||
Line 13: | Line 13: | ||
# What are their limitations? | # What are their limitations? | ||
# How suitable are these filesystems in modern small networks? Enterprise networks? Internet-scale applications? Why? | # How suitable are these filesystems in modern small networks? Enterprise networks? Internet-scale applications? Why? | ||
==Notes== | |||
===Bell Labs=== | |||
* tried to turn everything into a file | |||
* wanted to make OS easier to use for programmers of their systems | |||
* "simple" common API/protocol for I/O & IPC resources; "radical network transparency" | |||
* focus on process communication | |||
* portability | |||
* code reuse (of their own code), but ignored legacy code problem | |||
* "laziness" & "generality" | |||
* move from centralized to distributed computing to make use of the individual machines | |||
* resource utilization / efficiency | |||
* '''with Plan 9, you don’t know when you’re using a network (network transparency), because everything is just a file''' | |||
** is the overhead consistent? not always: this means that one can’t predict how "file" accesses will perform in the field | |||
** reliability of "file" access relies on reliability of network and remote machines |
Revision as of 20:17, 23 October 2008
Readings
- Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)
This is the original NFS paper.
- John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)
This paper describes AFS and compares it to NFS.
- Nelson, Welch, & Ousterhout, "Caching in the Sprite Network File System" (1988)
This paper compares Sprite to AFS and NFS.
Questions
- What were the key design goals of NFS, AFS, and Sprite's FS?
- How well did they achieve their goals?
- What are their limitations?
- How suitable are these filesystems in modern small networks? Enterprise networks? Internet-scale applications? Why?
Notes
Bell Labs
- tried to turn everything into a file
- wanted to make OS easier to use for programmers of their systems
- "simple" common API/protocol for I/O & IPC resources; "radical network transparency"
- focus on process communication
- portability
- code reuse (of their own code), but ignored legacy code problem
- "laziness" & "generality"
- move from centralized to distributed computing to make use of the individual machines
- resource utilization / efficiency
- with Plan 9, you don’t know when you’re using a network (network transparency), because everything is just a file
- is the overhead consistent? not always: this means that one can’t predict how "file" accesses will perform in the field
- reliability of "file" access relies on reliability of network and remote machines