NFS, AFS, Sprite FS: Difference between revisions
No edit summary |
Finished posting notes on NFS/AFS/SpriteFS/DSM |
||
(One intermediate revision by the same user not shown) | |||
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 from this and the previous week== | |||
Two main things to consider about new ideas for systems: | |||
* mental models | |||
* controls | |||
Are these solving some problem better than existing things, and are they better enough to overcome the disadvantages? | |||
===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 | |||
===DSM=== | |||
* tried to turn everything into RAM | |||
* wanted to make programming easier by not having to deal with sending data | |||
* resource utilization / efficiency (while still being DSM, as much as those conflict) | |||
* focus on a class of problems (not as general) | |||
* an abstraction of system resources ("is it the right abstraction?") | |||
* '''with DSM, you don't know when you're using a network (network transparency), because everything is just memory''' | |||
** is the overhead consistent? no: this means that one can't predict how programs will perform in the field | |||
** reliability of programs relies on reliability of network and remote machines | |||
With hardware-based DSM: processor doesn’t know what pages do and don’t need to be secure. It's also not a portable system design. |
Latest revision as of 20:29, 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 from this and the previous week
Two main things to consider about new ideas for systems:
- mental models
- controls
Are these solving some problem better than existing things, and are they better enough to overcome the disadvantages?
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
DSM
- tried to turn everything into RAM
- wanted to make programming easier by not having to deal with sending data
- resource utilization / efficiency (while still being DSM, as much as those conflict)
- focus on a class of problems (not as general)
- an abstraction of system resources ("is it the right abstraction?")
- with DSM, you don't know when you're using a network (network transparency), because everything is just memory
- is the overhead consistent? no: this means that one can't predict how programs will perform in the field
- reliability of programs relies on reliability of network and remote machines
With hardware-based DSM: processor doesn’t know what pages do and don’t need to be secure. It's also not a portable system design.